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ABSTRACT 


In computer program design it is essential to know the effectiveness of different 
design options in improving performance, and dependability. This paper provides a 
description of a CAD tool for distributed hierarchical Petri nets. 

After a brief review of Petri nets, Petri net languages, and Petri net trans- 
ducers, and descriptions of several current Petri net tools, the specifications and 
design of the TokenPasser tool are presented. TokenPasser is a tool to allow design 
of distributed hierarchical systems based on Petri nets. 

A case study for an intelligent robotic system is conducted, a Coordination 
structure with one dispatcher controlling three coordinators is built to model a 
proposed robotic assembly system. The system is implemented using TokenPasser, 
and the results are analyzed to allow judgment of the tool. 


CHAPTER 1 
INTRODUCTION 


1.1 Motivation 

1.1.1 System Specification 

Perhaps the most critical step in system development is the specification stage. 
It has been estimated that the cost of reworking an error discovered in the coding 
phase of a project is 50 to 200 times more expensive than fixing an error discovered 
during specification [4]. In addition to reducing the cost (and development time) of 
a system, a good specification insures that, the program does the desired task, and 
allows better estimates of the functionality and the time to produce a system. 

Some products allow automatic translations of specifications into runnable 
code. These tools help with system design in many ways, including 

• Reducing the number of errors introduced in converting specifications to code. 

• Allow quicker adaptation to changed specifications. 

• Allow easier testing of the results of specification modifications. 

• Assisting the developers in program verification. 

1.1.2 Distributed Hierarchical Systems 

Hierarchical distributed systems have been becoming more common, and more 
important. Hierarchical controllers process commands sent from higher levels, syn- 
chronize activities of lower level machines, and report states back to other people or 
processes. If this controller is controlling a distributed system, most processes will 
be asynchronous, synchronizing only when r.he controller requires it. A well designed 
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hierarchical controller will also allow modular connections of controlled processes, 
allowing for a much more versatile system. 

1.2 Petri Nets for Analysis of Distributed Systems 

Due to their ability to allow both synchronous and asynchronous activities, 
Petri nets are good tools for simulating and modeling distributed systems. Petri nets 
also allow rigorous mathematical analysis, including guaranteeing liveness, deadlock 
properties, reversability and boundedness. Since stochastic Petri nets can also be 
modeled as Markov chains, models can be mathematically analyzed to allow per- 
formance estimates. Finally, conventional Petri net graphical notation is intuitively 
easy to understand, thus allowing people to easily (if informally) analyze the net by 
playing the "token game”. 

Since Petri nets have nice specification properties (easy to understand, rig- 
orously defined, versatile, analyzable, diverse modeling capabilities), and they can 
be automatically translated to code they are am ideal tool for rapid prototyping of 
distributed systems. 

1.3 Goals of This Project 

Given the above motivation, the TokenPasser code was written to allow a user 
to define colored Petri net transducers (CPNT) which pass tokens across internet 
domain ethernets to allow rapid prototyping of distributed hierarchical control sys- 
tems. TokenPasser. when compiled with a suitable net definition file, allows the user 
to run any number of CPNTs which can communicate with the controller CPNT 
via sockets. The user can also enable a display of any or all of the CPNTs to allow 
monitoring of the progress of commands in the net. With the display off, the pro- 
gram runs at full speed, allowing testing ot speed and system loading of the designed 
net. Finally, routines or programs can be attached to each transitions in the net, 
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allowing more complete prototyping of the system, by attaching the routines which 
will actually be in the final system, or stubs which simulate the output or delay of 
the expected routine. 

1.4 Application: The CIRSSE Platform 

A platform system for robotic construction in space is currently under devel- 
opment at the NASA Center for Intelligent Robotic Systems for Space Exploration, 
Rensselaer Polytechnic Institute. The system consists of a platform with two PUMA 
manipulators mounted on moving bases. A vision system with five cameras is incor- 
porated into the system for object identification and location determination. The 
task scenario for the system is to assemble strut structures in a dynamic and uncer- 
tain environment on space stations. 

A major difficulty faced by the system is the long delay in communication 
between earth and the space station, therefore in order to make the system able 
to execute the construction in space, an intelligent control system with minimum 

human interaction has to be designed for the system. 

To this end. the theory of Hierarchical Intelligent Control System de- 
veloped by Saridis and his colleagues [20. 21, 24] has been applied here to design 
the system architecture of the platform system. This is accomplished by arranging 
the system into three levels: the Organization, Coordination, and Execution Lev- 
els, hierarchically ordered according to the principle of Increasing Precision with 
Decreasing Intelligence. The function of the Organization Level is to define con- 
struction missions and generate the high level task plans for some specific assembly 
tasks. The plans include the specification of structure configuration, strut/node 
assembling sequence, and motion commands. The Coordination Level serves as an 
interface between the Organization and Execution levels. Its main function is to 
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translate the higher level task plains into the specific operation instructions and co- 
ordinate their execution. Finally, the Execution Level is to execute the instructions 
using devices in this level. 

The specification and testing of the coordination level of the platform system 
is an ideal test for the TokenPasser program, and the case study section of this 
paper deals with the development and testing of that communications protocol. 

1.5 Thesis Outline 

This thesis is organized in five chapters and two appendices. Chapter 2, the 
literature review, is divided into two sections. The first section discusses Petri nets, 
Petri net languages, and Petri net transducers. The second section discusses some 
of the Petri net tools available for system modeling and creation, then goes into de- 
scribes in further detail two tools for distributed system design. Chapter 3 presents 
the problem statement in terms of a project specification, then details the design 
of the project. Chapter 4 presents a case study, the dispatcher for a distributed 
robotic arm control system. The chapter presents the physical system being used, 
details the design of the Petri net transducer controllers for each subsystem, and 
provides a structural analysis and the results from a distributed simulation of this 
system. Chapter 5 summarizes the thesis with conclusions and gives suggestions 
for further development of the TokenPasser tool. Appendix A gives the C code for 
the TokenPasser program. Appendix B gives the C code for the descriptions of the 
developed Petri nets. 


CHAPTER 2 
LITERATURE REVIEW 


2.1 Petri Net Theory 

2.1.1 Petri nets 

In this section we give a brief introduction to Petri net theory. Note that 
although only ordinary Petri nets are treated here, we will use the concept of colored 
Petri nets in our model for the coordination level, since it has been proven that as 
long as the number of colors is finite the colored Petri net model is equivalent to a 
one or more ordinary Petri nets [18]. 

Petri nets are tools for modeling the dynamic behavior of discrete event sys- 
tems. They consist mainly of two types of elements: places and transitions. The 
places represent the state of the system, while the transitions represent events which 
change the state of the system. A place can contain a non-negative number of to- 
kens. The state of the system modeled by a Petri net is given by its marking (the 
number of tokens in each place). The system evolves by firing transitions according 
to the execution rule described in definition 2.4. 

Definition 2.1 A Petri, net is a quadruple. 

N=(P.T.I,0) where: 

1. P and T are finite sets of places and transitions , where 

POT = 0 and P U T ^ 0 

2. I:PxT — *• Z is the input function. 

3. 0:PxT — Z is the output function. 


where Z is the set of natural numbers. 
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Figure 2.1: A Petri net with tokens 

A Petri net can be represented by a bipartite directed multigraph, the Petri 
net graph. Places are represented by circles, and transitions by bars. There is an 
arc joining a place p to a transition t iff then p is called the input place of 

f. Analogously, there is an arc from t to p iff 0(p,t) ± 0, then p is called the output 
place of t. Natural numbers I(p.t) and 0(p,t) are called the weights of the arcs. 

Definition 2.2 A marking m of a Petri net N is a function m:P—Z. m gives the 
number of tokens in each place p €P- 

A token can be represented by a dot. Figure 2.1 shows a Petri net with it’s 
initial marking m 0 (pt) = m o(pri = m o(/»3)= 0- 

Definition 2.3 A transition t is enabled with respect to a marking m iff m>I(t) 

Definition 2.4 (execution rule) Firing an enabled transition t consists of remov- 
ing I(p,£) tokens from each input place p and adding 0(p,i) tokens to each output 
place p. Let m t be the new marking resulting from firing t under the marking m 0 , 

then mt = mo +0(t) * U^)* 
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Definition 2.5 (reachability set) The reachability set, R(m), for a Petri net N 
with initial marking m is the set of all markings of N which can be reached from m 
by firing a finite number of transitions of N. 

The following are important properties for Petri nets: 

Definition 2.6 (Deadlock) A deadlock occurs in a Petri net when a marking is 
reached where no transitions in the net can be fired from that point on. 

Definition 2.7 (Liveness) A Petri net is live with respect to a marking m if, for 
any marking in R(m), it is possible to fire any transition in the net either immedi- 
ately, or after firing a sequence of other transitions. Liveness guarantees the absence 
of deadlocks. 

Definition 2.8 (Reversibility) A Petri net is reversible with respect to a mark- 
ing m if for every m’€ R(m), m€R(m’). Reversibility guarantees that the system 
modeled by the Petri net can re-initialize itself. This is important for error recovery. 

Definition 2.9 (Boundedness) A Petri net is bounded with respect to a marking 
m if there exists a finite number k, such that, for any marking in R(m) the number 
of tokens in each place in the Petri net is less than or equal to k. A net which is 
bounded by the value k is said to be k-bounded. if k = 1, the net is safe . 

2. 1.1.1 Petri Net Languages 

The purpose of introducing Petri net language is to characterize the behavior 
of a Petri net model by the specification of action sequences of the net. Although 
various formulations for PNL have been suggested in the literature [19], in order to 
be consistent with our definition of Petri net transducer which will be introduced 
later, we give a general definition for PNL. 
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Definition 2.10 A Petri net language generated by a labeled Petri net 7 = 
is a set of strings over E 

£( 7 ) = P(<*) € E-||o € L(N lf t) and 6 (n,a) € F . .. 

where 

• N = (P,T,I.O) is a Petri net with the initial marking p. 

• E is a finite alphabet. 

• 0 :T— > (E U {A}) is a labeling function. 

• F C R(/z) is the set of final markings. 

Note that the superscript * denotes the set of all strings of symbols formed from the 
stared alphabet, including the empty string. 

Different types of PNL can be obtained by considering various restrictions 
placed on the labeling function 3 and the final marking set F. 

2 .1.2 Petri Net Transducers 

Definition 2.11 A Petri net transducer ( P NT), M is a 6-tuple, 

M =(N,E, A. cr.p, F) where 

• N=(P,T,I.O) is a Petri net with an initial marking p. 

• E is a finite input alphabet. 

• A is a finite output alphabet. 

•o’ is a translation mapping from Tx(E U A) to finite sets of A". 

• FCR(^) is a set of final markings. 



9 



Figure 2.2: The configuration of PNTs 

i the set 0 f primitive tasks for task planning, and A. the 
Physically, E may represent the set ot prin 

primitive set of operations for task execution. 

** , c_ ir( , 2 2 There are three parts to a 

A PNT can be pictured as shown in gu • • f 

, , . a Peln confer, and an output tup. The bebavror of 
PNT: an input tape , a retn 

• el rWribed in terms of the configuration of the PN . 
a PNT can be conveniently descnb 

. iion of PNT M is defined as the triple (m. x, y) where m SR 00 

rrr r« - * x 6 * - - - - - — 

input tape, with the leftmost symbol of x under the input head; y € A ,s t e ou 

string emitted up to this point. ... 

S “ 6 PNTs in 251 indicates that 

An investigation of the language properties * 

el l nd therefore can be used to model that dispatcher 
PNTs are self-consistent models, and theielo 

'stentlv Wans 125) discusses the advantages of synchronous 
and coordinators consistently, wang ^ l 

rdinate two PNTs, and the language resulting 
composition as a mechanism to coordinate two 

from this composition. 
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2.1.3 Coordination Structures 

A coordination structure (CS) is constructed in [23] by integrating Petri net 
transducer models of the dispatcher and coordinators through a set of connection 
points. The connection constraints in the definition of a CS guarenetee that each 
coordinator only receives tasks from the dispatcher when the coordinator is available, 
and the coordinator can only report the execution results when the dispatcher is 
ready. 

Two useful theorems are proven in [23]. They are: 

Theorem 1: The Petri net underlying a CS is bounded if the Dispatcher and all 
of the Coordinators are bounded. 

Theorem 2: The Petri net underlying a CS is live if the Dispatcher and all the 
Coordinators are live. 

2.2 Current Tools 
2.2.1 Petri Net Tools 

Petri nets have been extensively used for modeling distributed systems. They 
are very popular because of their capability of clearly describing concurrency, con- 
flicts and synchronization of processes. 

There are many Petri net tools which have been developed to assist in program 
design. These tools generally fit into one of two classes: 

1. Design tools which assist in the construction of Petri nets, and allow one to 
determine several properties of the nets via either simulation or mathematical 
analysis[ll. 15, 13]. 

2. Tools which assist in the creation of logic controllers. Normally these tools take 
a Petri net description of a system and automatically translate that description 
into some sort of executable code[l6. 2, 8, 17]. 
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Realistically the second group of tools is only likely to be used on nets which have 
been verified (for whatever criterion the designer is interested in) with one or more 
of the first set of tools. 

This is a brief summary of the leading Petri net tools: 

2.2. 1.1 GreatSPN 

This tool, as described in [7], provides a graphic editor for easy construction 
and editing of Petri nets with timed, immediate, and stochastic transitions. It is 
currently being expanded to include colored nets. It’s analysis capabilities include 
calculation of place and transition invariants, boundedness, steady state token dis- 
tribution, and time based performance. The performance can be calculated through 
either "Monte Carlo" simulations, or through analysis of the embedded Markov 
chain. GreatSPN also allows the user to debug the system by playing the "token 
game” . 

GreatSPN is somewhat limited in it's ability to analyze large nets, and also 
doesn’t support connection of any two previously designed nets. 


2. 2. 1.2 SPNP 

This tool, as described in [10] reads a text description of a Generalized Timed 
Petri Net model, builds the embedded Markov chain, and the reachability graph for 
that model, solves the steady state equations for the Markov chain, and computes 
any "resource estimates" (means and distributions) requested in the model input. 

This analysis is comparatively fast, and can handle very large nets, however 
writing the text description of any large net is somewhat difficult, and is likely to 
be error prone. To simplify writing the text description, there do exist tools for 
translating GreatSPN net descriptions into the input files for SPNP. 
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2. 2. 1.3 Design /TDEF, Design/CPN 

Design/IDEF[11] translates from an IDEF specification to a Colored Petri Net 
description. These descriptions can then be analyzed by the Design/CPN package 
by playing the "token game”. The Design/CPN package also supports creation and 
editing of Colored Petri Nets, including the ability to combine two different nets by 
substitution, invocation, or fusion. The CPN package also supports attaching code 
segments to transitions, so that these code segments can calculate values for output 
tokens, or perform other functions. 

2.2.1. 4 GRASPIN 

GRASPIN[ll] supports agraphic design of Predicate/transition nets and Pr/E 
nets. The tool can check the consistency, completeness and termination properties of 
the nets. The tool allows simulation of these nets, reachability and liveness analysis, 
transformation from P/T nets to specifications, and finally compilation of the net 
to lisp functions. 

2.2. 1.5 PACE 

Pace [11] system allows graphical editing of hierarchical nets, with inhibitor 
arcs (an extension which makes Petri nets equivalent to Turing machines, but re- 
duces the analyzableity of the net). From this description the tool can generate a 
C program with equivalent behavior. 

The analysis available with this tool is a "token game" simulator with both 
forward and backward simulation, breakpoints, and modification of the net during 
simulation. 
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2.2.1.6 TEBE 

TEBE [11] takes the 1 -safe net and produces a reduced net performing the 
same function. 

2.2.2 Distributed System Tools 

Other than Petri net modeling systems, which could model distributed systems 
by modeling the the communication network, none of the Petri net tools found dealt 
with distributed systems. There are, however, several systems which allow design 
of distributed controllers. Two approaches are detailed here. The first is interesting 
due to the improvement in the development times of the built systems. The second 
is an example of a distributed system controller design tool built on the Unix system. 

2. 2.2.1 C-nets 

Murata et al. [16] Describe a Control net (C-net), an enhancement of a Petri 
net which they use to build a micro- computer based controller which controls some 
machinery by running the C-net. 

A C-net is defined by the LO-tuple CN = (P,T, I, O, *,<?,»?, U, V, M) where P, 
T, I, O and m are the same as in the standard Petri net model. 6,<p, and 77 are called 
process I/O functions, and U and V are process status functions. These functions 
are used to define process interfaces and process statuses. 

Process I/O Functions Let A be a set of control signals (x { ) and E a set of 
observable signals (y {j ) then 8: P->A, *:P-E, and rj: T-E are defined as follows: 

8(pi) = x;, (x t - € A, pi 6 P) 

'p(pi) — (y«ii y*2. • • • . yin)- ( y<j £ £•> p> ^ 

= yik, (//« * € E,ti € E). 
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When a token enters place p f , a control signal x u defined by <5(p f ) is put out and 
a machine action is triggered. The token stays in the box until one of the input 
signals y,i, • • • , Pin defined by <p(p,-) is detected as a response signal of a completed 
action. 


Process Status Functions To define the action’s execution status at a place 
and to manage transition open/close statuses, process status functions U:P— +L 
(L=0,1,- • • ,q), V:P— (N= 0,1) are defined as follows: 


U{ Pi ) = 


0 


m 


action associated with p,- is executing now 

action associated with p,- is completed with return code y ln 


V(U) = 


0 

1 


ti is closed 
f; is opened 


By introducing these functions, action execution statuses or transition operation 
modes can be supervised at a place or transition. 


Transition Firing Rule A Transition t, € T can be enabled at marking rri\ iff: 

^(^t) = 1, M{pi) = 1, U{pi) =£ 0, and Mi(p } ) = 0 for all p,- € I{U) and pj € 0(t;) 

By firing t x tokens are generated in all output places and deleted from all input 
places. When the tokens are generated, the output signals defined at the output 
places of ti are put out and U(p ; ) is set at 0. 

Based on this model a C-net interpreter was designed and installed on a micro- 
computer system. The operator could draw a C-net on a graphic display, and input 
control tables. The monitor displays the machine status in real time by displaying 
tokens in the active places. 

Three experiments were described, an assembly station, a robot controller, and 
a general flexible manufacturing ceil controller. The software development times 
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were reduced by 50 to 80 percent compaxed with the relay ladder diagram method, 
and the system maintenance time was reduced by 60 percent. 

2. 2.2. 2 The Olympus Simulation System 

The Olympus Modeling system[l7] is an interactive, distributed model inter- 
pretation environment for bilogic precedence graphs (BPGs). BPGs, like Petri nets 
represent the status of the model through a distribution of tokens on nodes and 
edges. An interpreted BPG corresponds to a simulation model of some system. 

The Olvmpus system is an interesting tool because it allows a user to define 
and simulate a distributed system with a distributed simulation. 

Olympus consists of a frontend and a backend, the frontend implements the 
user interface, while the backend provides storage and interpretation of the model. 

An Implementation Figure 2.3 illustrates an implementation of Olympus in a 
network of Sun workstations, using Unix processes, graphics and network protocols. 
The frontend is a point and select editor built on Sun’s NeWS model, implemented 
as a NeWS client and a NeWS server. The client implements the logical aspects of 
the user interface, while the NeWS server process is responsible for placing images 
on the display. 

The Olympus server (backend) is implemented as n+1 Unix processes. The 
first process multiplexes among the four interpretation and storage subproceses. the 
other n processes are used to evaluate BPG interpretations. The BPG interpreta- 
tions can be defined in any language, provided that the definition can be called as 
a C procedure. The task interpreter uses the Sun Remote Procedure Call facility 
to invoke the interpretation procedure whenever the corresponding node is fired. 
The result of this is that the tool runs a single BPG net, with the firing of each 
node starting a procedure on some (possibly remote) machine. This allows the rapid 
prototyping and simulation of distributer! systems. 
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Figure 2.3: An Olympus Implementation 













CHAPTER 3 
PROBLEM STATEMENT 

3.1 Project Specification 

The object of this project is to build a tool which allows the user to define 
distributed hierarchy of communicating colored Petri net transducers. We wanted 
to be able to 

• Distribute the Petri nets on different machines, with easy ways of changing 
the connections between different nets, or the machine on which a net runs. 

• Have a graphical display, to allow the user to allow the user to inspect the 
progress of the net. 

• Attach routines to any or all of the transitions, to allow more detailed simu- 
lations. 

Because they are all common and versatile systems, this tool is being developed as 
a C program to run under the Unix operating system, using the Xll windowing 
system for any displays. 

3.2 Project Design 
3.2.1 Communication 

The communication between the processors is an important issue. Since it was 
decided to build this program on the CIRSSE Unix system, the Unix methods of 
communication were most available. 

A socket is a Unix Inter Process Communication (IPC) construct, which al- 
lows communication between processes on multiple machines. Sockets allow many 
options including non-blocking reading and writing, and asynchronous notification 
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of data arrival. Functionally sockets look like files, they can be written to, or read 
from with the read(2) or vrite(2) commands. Sockets have many communica- 
tion semantics, the most convenient one was the SOCK_STREAM which provides 
sequenced, reliable, two-way byte streams. Sockets also use several different proto- 
cols, the most relevant one is PF.INET, which is an internet protocol, which provides 
enough versatility to go across ethemets. 

Since all UNIX IPC is built upon sockets, sockets are the fastest built-in 
communication method possible, and due to the relative ease of writing and reading 
data using them. SOCK_STREAM, PFJNET sockets were the tool used. 

3.2.2 Data Structures 

To run a Petri net transducer one must be able to locate ail enabled transitions. 
This program is also required to run a routine at each transition. Since the Petri 
nets are colored, and this is a Petri net transducer, each transition must have a 
set of tokens which enable it, and a set of “menu” commands which allow the 
particular transition to fire. From this we decided on a set of data structures for the 
implementation of the Petri net transducer: Each transition is a structure, pointing 
to 


• the function which the transition must run, 

• a list of pointers to the pre-places of the transition, 

• a list of pointers to the post places. 

• a list of "menu" 1 commands which enable the transition 


• a list of token '‘colors” which enable the transition. 
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struct transition { 

struct pre.pointer *pre_places; 
struct post .pointer *post .places ; 
int (*routine) () ; 

struct enabelors *enabled_by; /*valid token "colors". */ 

struct enabelors *menu_requirements ; /* this refers to the*/ 

/* values required in the "menu"*/ 
int consumes. menu; /*this increments the menu ptr? */ 

int x.loc; /*for graphic output */ 

int y.loc ; /*for graphic output */ 

>; 


Each place is a pointer to a list of objects (currently integers) which are in the 
place. Each transition is connected to its pre and post places by a set of pointers 
which point to structures which point to the place. These pointers (pre_pointers, 
and post .pointers) also point to the routine associated with coloring each token 
before feeding it to a transition and decoloring it on the way out, in the case of 
post.pointers there is also a pointer to the routine which should be used if the data 
is to be sent to a remote machine. 


struct place.ptrf 

struct place.contains *place; 

int x.loc; /*for graphic output */ 

int y.loc; /*for graphic output */ 

>; 

struct place.contains-C 
int ob j ect ; 

struct place.contains *next .content 3; 

>; 


struct pre.po inter { 

struct place.ptr *place; 
struct pre.pointer *next .place; 
int (*decoloration_routine) () ; 
>; 


/♦returns true if it enables */ 
/♦transition, false otherwise*/ 
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struct post.pointer { 

int remote; /* =0 if local otherwise it is a */ 

struct place_ptr *place; /* pointer to the socket if remote */ 

/* this points to an integer with a*/ 
struct post_pointer *next_place; /* value=the position in the*/ 
int (*data_trans_routine) () ; /*array for the remote value*/ 

int (*coloration_routine) () ; 

>; 


Figure 3.1 displays how all of these structures fit together. 


3.2.3 Flow of Control 


Each sub-net is run by one block of code. The main block sets up one socket 

for each of the other blocks, and prints out files giving the “address” of each socket. 

It then waits for the other three routines to connect to it. The auxiliary programs 

start up, and connect to the given socket. Each of the programs then initializes its 

Petri net, and starts trying to fire transitions. 

Given the data structure described in the previous section it is easy to write 
code to run the Petri net. Specifically it looks like: 


while (TRUE) 

{ 


for 

> 


(j =0; j< num_transitions ; j++) 

if (transition_enabled_p (transitionfj] ) 
f ire_transition(transition[j] ) ; 


This code checks each transition, and if it is enabled fires it. The algorithm for 
determining if a transition is enabled in a colored Petri net transducer is slightly 
complicated, the pseudo code for it looks like this: 

transition_enabled_p (transit ion) { 

if (transition->menu_requirements « NULL) 
if (transition. enabled.by == NULL) 

if ( at _least _one_token_ in_each_preplace (transition) 
return (TRUE) ; 
else return(FALSE) ; 
else {. 

f or (token=transit ion . enabled.by ; token=token . next ; 


enabelor 


token. 


transition 


function 

x 



next 

place-contains 


Figure 3.1: The Data Structures of the TokenPasser Program 
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token»*NULL) 

if (at_least_one_token_per_plac9_match.es (token) ) 
return (token) ; 
return (FALSE) ; > 

else 

if ( at _ least _onematch.es (trans->menu_requirement , 

current _menu() ) 

if (transition. enabled.by « NULL) 

if (at_least_one_token_in_each_preplace (transition) 
return (TRUE ) ; 
else retum(FALSE) ; 
else { 

f or (token=*t ransit ion . enabled.by ; t oken=t oken . next ; 
token==NULL) 

if (one_token_per_place_matches (token) ) 
return (token) ; 
return (FALSE) ; } 

return (FALSE) ; 

} 

Once it is determined that a transition is enabled, firing a transition consists of: 
removing one (appropriately colored) token from each pre-place, running the routine 
associated with the transition, re-coloring the token, and putting it in each post- 
place, and incrementing the '‘menu" pointer if the transition required a “menu’ 
command to fire. 

Note, one flaw with the present system is that it is impossible to specify that 
a certain transition requires multiple tokens from one place. 

3.2.4 User Interface 

The input data for the Petri net is entered in the form of a file which is 
compiled with each program. This program has an X- window graphical display as 
output. This display shows the Petri net, and the tape for the net, along with the 
current marking of the net. This allows the transmission of data and commands to 
be seen, in addition to the overall command structure for the the defined nets. 

Each net is run by it’s own block of code. If the user chooses to observe the 
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firings of the net the block of code forks to two processes, the first of which runs the 
net as described in the previous section. The second block monitors and updates the 
display, which allows the display to be moved, resized, or hidden without interfering 
with the progress of the firing of the net. Of course, under normal conditions, the 
transitions fire to quickly to allow the user to observe the net, so when the display is 
”on” there is a 300 mS delay built into each transition, so the user can see it flash. 
If the user doesn’t display the net, the 300mS delay is not enabled. 


CHAPTER 4 
CASE STUDY 


4.1 CIRSSE System Overview 

4.1.1 Goals 

One of the present goals of the CIRSSE platform project is to be able to 
assemble struts and nodes autonomously onto some well-defined structures in a 
space environment. For this task it has been assumed that there are only three 
classes of objects in the workspace of the platform: struts, nodes, and obstacles. 
The obstacles may travel in the workspace in some unpredictable ways, and the 
platform system has to avoid the possible collision with them during the process of 
construction. 

A completely autonomous Organization Level for the platform system is not 
considered at the current stage. Therefore, its function is replaced by a human op- 
erator in the earth station. In order to make the Coordination Level understand the 
tasks from the Organization Level (which may be a human operator), a formalism, 
called system command language, for expressing the construction missions by the op- 
erators is designed, and the input to the Coordination Level will be compiled system 
commands (or task plans). Obviously, to reduce the communication required be- 
tween the earth station and the space station, the compiler for the system command 
language should be hosted on the space station with the Coordination Level. 

Due the constraint imposed by earth-space communication, the Coordination 
Level has to be able to operate under the situation that task commands from the 
high level arrive infrequently and erratically. To accomplish this, the dispatcher (D) 
of the Coordination Level should 

1. Decompose the task commands into subtasks and dispatch them in order when 
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the relevant coordinators have signaled that they are ready for the next exe- 
cution. 

2. Communicate with the coordinators relatively quickly; 

3. Be capable of setting up communication between any two coordinators which 
need information exchange. 

The three coordinators of this Level axe: the vision coordinator (VC), the gripper 
coordinator (GC) and the motion coordinator (MC). The system components of the 
dispatcher and the coordinators are described in sequel. 

4.1.2 System Components 
4. 1.2.1 Dispatcher 

As noted in the goals, the communication time to the dispatcher may be er- 
ratic, however, we require the dispatcher t.o communicate quickly with any of the 
coordinators. Because of this all of the coordinators are designed to allow (rela- 
tively) long waits between commands. Additionally, the dispatcher is not involved 
in transmission of large blocks of data. If large amounts of data is expected to 
be passed from one coordinator to another, then the dispatcher just instructs the 
coordinators to connect to each other, an allows them to communicate at whatever 
rate they are capable of. 

The dispatcher is physically realized on Sol, a SUN4/260 workstation. The 
dispatcher communicates with the coordinators through THINNET, a version of 
ETHERNET. The communication will be implemented with IPC SOCK-STREAM 
type sockets, under the IFJNET protocol. This Implementation results in a mini- 
mum turn around time of 200m S from one processor to another and back. 
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4. 1.2. 2 Vision 

The vision coordinator has the job of “looking” at an area that it is told to 
observe, and attempting to find something which it has been told to find there. It 
then gives the location of said object back to the system which asked for it, and 
waits for another command. The location of an object includes it s position, and 
orientation, and in the case of obstacles, a simple description of it’s surface. 

The vision system is physically realized on a VxWorks cage with a Data cube, 
and a Motorola MVME147 controller. The controller is connected to the ethernet, 
and thus to the rest of the system. The Datacube boards consist of: 

SNAP The SNAP board performs non-linear transformations (comparisons and 
max/min determinations) in sequential digital video data. 

VFIR-MKIII A video impulse response filter module. It implements a 256 ar- 
bitrary coefficient convolution. This is primarily used in edge detection, and 
noise filtering. 

Max-SP This is capable of performing real time frame rate single point tempo- 
ral and spatial filters, image merging, image subtraction and addition, and 
Min/ Max processing. 

FEATUREMAX-MKII this does advanced feature-list extraction, and histogram 
grams. A summation of all row or column pixels can be done in a table. 

MAX-MUX This provides the MaxVideo user with software control over MAXbus 
data source and destination selection. This allows for easier reprogramming 
of the Datacube. 

DIGIMAX This is a video acquisition and display module which is capable of 
accepting one of eight inputs. This is used to feed the information from the 
cameras to the ROI-STORE units. 
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ROI-STORE this is a frame storage module which supports user programmable 
video resolution and processing of regions of interest within a video image. 

Since there are two DIGIMAX cards two frames can be read simultaneously. 
Two of the cameras are mounted on the manipulators, allowing greater diversity in 
the objects which can be viewed, but presenting greater challenges in calibration. 
Two of the remaining cameras are mounted on the ceiling of the workspace, and the 
remaining one has not yet been placed. 

The each frame grabber is capable of reading the cameras at a rate of 30 Hz. 
The output of the Datacube is sent to the MVME147 which can further analyze the 
image and send data to other coordinators. The MVME147 does any intermediate 
level operations, such as Hough transforms, or line fitting. 

The Uniphase laser is controlled by the Motorola MVME 135 CPU, and the 
MVME :'40 parallel board. The laser is used to put bright points on the object, to 
make stc eo point matching easier. 

4. 1.2. 3 Arm 

T * motion system is used to move objects in the environment, and to move 
camera which are attached to the robot arms. The motion system is also directly 
used b he vision coordinator during calibration. 

<; motion system is physically realized on a Vx Works cage running 5 Mo- 
torola IV ME 135 boards (68020 CPUs), along with 

MWi £340A A parallel port board, which also supplies timer interrupts. This is 
used to read the sensors, and supply interrupts for the platform servo control. 

VMIV ME 2532A A digital I/O board, which is used primarily for switching ex- 
ternal circuits, thus allowing software control of power to any of the manipu- 


lators. 
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DVME 628 A D/A converter, for supplying motor currents to the arms. The 
digital signal is converted to analog, and then run through a servo amplifier 
and fed to the joints in the system. 

MVME 224-1 Four MBytes of shared memory. 

XVME 556 A 16 channel A/D converter, which is currently unused, but may be 
used for reading encoders. 

Whetdco Encoder A VME 3570 Optical shaft encoder, used for reading the po- 
sition of the carts on the Aronson platform. 

VME 7016 A VME Q Bus controller, used to control the Puma. 

332 XT Eight channel serial interface. This will be used to control the gripper. 

The 68020s connect via the databus to a D/A board which feeds currents to a Puma 
560, and a puma 600 arm. The puma arms have absolute position potentiometers, 
and torque sensors at all of their joints. Each arm is mounted on an Aronson plat- 
form which gives each arm three more degrees of freedom. The arms and platform 
are controlled by Kali, [22] an integrated path planner/arm controller. 

4.1.2. 4 Gripper 

The gripper will be used to actually grasp struts and nodes. It must be able 
to sense when there is an object between its “fingers”, report the position that the 
fingers are in, and the force they are applying. The gripper is a pneumatically 
controlled gripper. Each gripper is equipped with an crossfire sensors, and force 
sensors, and is mounted on a Lord force/ torque sensor, which is mounted on the 
end of the puma arm. The gripper controller is a Motorola 68HC11 based controller, 
which communicates with the VxWorks cage through the 332 XT serial interface in 
the VxWorks cage. 
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4.2 System Command Language and Task Grammar 

As mentioned in the previous section, a system command language is necessary 
for the Coordination Level to interact with the human operators in the Organization 
Level. This high level language will also make the programming of the construction 
missions much easier for operators. 

A general formalism for the system command language can be defined by 
following the syntaxes of the existing high level languages, such as Pascal and VAL- 
II. One of such examples is the command formalism developed by Noreils and Chatila 
(1989) for a mobile robot system. However, since this paper is concentrated on the 
Coordination Level of the platform system and the inputs to that Level are only the 
compiled system commands (that is, sequences of tasks which are directly related 
to the operation of the Level), no attempt to specify a formal language for system 
commands will be made here. Instead, we define the following task grammar G to 
represent the compiled system commands to the Coordination Level: 

G = (S, N, E 0 , P) 

where 

E 0 = {calR, calV , move, slave, approach, release, grasp, 
findS I N , f indO B S continue .id si on} 

N = {S,V,M,M„M v ,H„ H sl , H 3i , H v , H vl , H vl } 

P = {5 — calR M 

M — * calV V | move M, 

M, — * move M, | approach M, \ approach H, 

H, — * release H 3l 

H,i — ► grasp H si \ move H , i | approach H si | calV V 
H s 2 release H v | release \'l. 
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V -* findS/ N V | findOBS V \ move M v | approach M v | slave V t 
V t —*■ continue. vision V 

M v —*■ move M v | approach M v | approach H v \ V 
H v — *■ release H vX 

H vl —*■ grasp H v2 \ move H vX | approach H vi \ V, 

H v2 release H v \ release M v 

V, M. M„ M v , H„ H, x , V t , H v , H vi -> 5} 

represents the set of task primitives (terminal symbols), N is the set of 
non-terminal symbols with S as the start symbol, and P the set of production rules 
for deriving task plans (or language). 

The task grammar G characterizes the basic task precedences in the operation 
of the platform system. With this given grammar, the problem of establishing the 
Coordination Level becomes that of constructing a coordination structure which is 
capable of processing all the task plans generated by G. This will be accomplished in 
th following section by giving the individual Petri net transducers for the dispatcher 
and coordinators. 

4.3 Coordination Structures 

4.3.1 The Petri Net Transducer for the Dispatcher 

The simplified Petri net model for the dispatcher, shown in figure 4.1 consists 
of 12 places and 16 transitions. A transition generally represents dispatching a 
command to perform a specific task, while a place represents the state of the system. 
These places and transitions are specified as follows: 

Transitions: 


CalR: Calibrate the Robot arm. 
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Figure 4.1: The Simplified Dispatcher Architecture 


Vision TMr Gripper jT\ Motion 
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Ml, M2, M3, M4, M5, M6: Send a Move or Approach command to the 
Motion Coordinator. 

Rell, Rel2: Send a release command to the Gripper Coordinator. 

Grip: Send a grip command to the Gripper Coordinator. 

VI, V2, V3: Send a find obstacle, find strut, or find node command to the 
Vision Coordinator. 

CalVl, CalV2: Send a Calibrate command to the Vision Coordinator. 

Con_V: Continue the interrupted vision task. 

Places: 

C: Holds a token if the vision system has been calibrated. 

UC: Holds a token if the vision system is not calibrated, and at least one 
move command has been done. 

S, M, Ms, HI, H2, V Vt: These places correspond to the non-terminals in 
the grammar. 

Vision, Gripper. Motion: These three places each represent four input and 
output places and semaphores for each of the three subnets. 

The full Petri net model for the dispatcher, 4.2 consists of 37 places and 32 
transitions. For simplicity, the simplified model will be discussed, as understanding 
all of the places and transitions is not necessary for understanding the net. 

The input alphabet for the dispatcher is the set of primitive tasks from the 
organization level. The output alphabet . i.e., the set of primitive control actions in 
the Coordination level is = Ao = where and E m are >-he 

input alphabets for the vision coordinator, the motion coordinator, and the gripper 


coordinator. We have : 
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Figure 4.2: The Dispatcher Architecture 


OUT_Grip 
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_ 2 0 = {Calibrate v , Look v , Find v , Slave, C ontinue.vision , Cahbrate m , 
Move „ », Approach m , Grasp g , i?e/ease 5 } 


The translations for all of the o^s for the dispatcher is as follows: 

The translation mapping for o’^Con-V'. continue-vision ) can be specified as. 

send_tape(vision_socket , Insert _tape_ immediat e , Continue), 

The translation mapping for Look ) can be specified as. 

send_tape(vision_socket , Append_to_end, Look, Return); 

The translation mapping for cr d {V n , Find v ) can be specified as: 

send_tape(vision_socket , Append_to_end, Find, Return), 

The translation mappings for cr<j(i2e/l, Release g ) and cr d (Rel2, Release g ) can be 
specified as: 

send_tape(gripper_socket , Append_to_end, GoPosition, Return), 

The translation mapping for o d (Grip, Grasp g ) can be specified as. 

send_tape(gripper_socket , Append_to_end, GoPosition, Return), 

The translation mappings for <r d {Cal\ L. Calibrate v ) and <r d (CalV2, Calibrate „) 
can be specified as: 

send_tape(vision_socket , Append_to_end, CalV , CalV, CalV, CalV, 
CalV , CalV , CalV , Return) ; 

The translation mapping for <r d {C alR.C alibrate m ) can be specified as. 

send_tape(arm_socket , Append_to_end, CalR) ; 

/* we are considering removing this co mm a n d from the */ 

/* grammar, as it only needs to be implemented every */ 

/* 6 months, not every time the system is brought up */ 
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The translation mapping for <r d (M n , Approach m ) can be specified as: 

send_tape(arm_socket , Append_to_end, Approach); 

The translation mappings for <r d (M n , Move) and cr d (M n , Slave ) can be specified 
as: 


send_t ape (arm_ socket , Append_to_end, Move); 

All other transitions of the dispatcher are internal operations. 

4.3.2 Petri Net Transducer for the Vision Coordinator 

The Petri net model of the vision coordinator in figure 4.3 consists of 15 places 
and 16 transitions. The transitions generally represent lower level routines, while 
the places represent the state of the system. The places and transitions are specified 
as follows: 

Transitions: 

Look: is fired to direct the vision system to “look” at a given location. 

NMv: No Move is fired if no arm movement is required to ■‘look” at a given 
location. 

Mv: Move is fired if arm movement is required to “look” at a location. 

BMv: Begin Move is fired to send the move command to the motion coordi- 
nator. 

Cal: Calibrate is fired when the calibrate command is given. 

Find: is fired to give the command to find a strut, node or obstacle in the 
scene that the vision system is already looking at. 


a 
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Figure 4.3: The Vision Petri Net Transducer 


Dalacube 
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EMv: End Move is fired when the Motion system returns a non-error value 
and the menu command is calibrate. 

BL:Blocks until the Datacube is free. 

FG: the Frame Grabber gets the picture from the cameras, and sends the 
data to the Datacube. 

BAn: Begins Analysis of the picture in the case when another move command 
must be sent to the arms. 

EAn: Analysis is complete, and the Datacube is returned to the available 
state. 

BA2: Analysis Begins for the case when the task is about to be completed. 

EA2: Analysis Ends, and the state of the net is reset to ready, while the 
results axe sent to Out. 

Cont: Fired when a "’continue action” command is given. Informs the Vision 
net that the event it was waiting on (am arm motion) is completed. 

NW: Fired when the net receives a "continue” command when it isn’t waiting. 

Places: 

In: The input place. 

Out: The output place 

Ready: Marks the availability of the system. 

IS, OS: The input and output semaphores. 

Datacube: Marks the availability of the Datacube. 

Anl. An2: Analyzing: the Datacube is processing information. 

AFin: The arm is finished with it’s action, or a continue command was sent. 

Mov: The arm is moving. 
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PMove: Prepare to Move the arm 
WFD: Wait For Datacube. 

HF: Have Frame. 

DW: Decide Where cameras need to be to ”look” at the given location. 
WFFG: Wait For Frame Grab. 

The subtasks to be processed by the vision coordinator are: S v = {look, F ind, 
calibrate joi si on, return, continue }. The output alphabet A„ consists of hardware 
related operations for the camera devices, and commands to the Motion coordinator. 
The translation mapping for the vision coordinator is expressed as follows: 
The translation mapping <r v {Look , look ) can be specified as: 

look_at (x , y , y , cameras. allowed) 

float x,y,z; /*The location, we want to look at*/ 

boolean cameras .allowed [] ; /*specifies cameras we may use*/ 

{ 

int i ; 

f or(i=0 ; i< NUM.CAMERAS; i++) 

cameras_allowed[i] &= can_be_pointed_at(x,y,z, i) ; 
if (number.of .allowed (cameras .allowed) < 2) return (ERROR) ; 
else enable_two_best_cameras(cameras_allowed) ; 
return (enabled.camera.descriptor) ; 

> 

The translation mapping <r v (.\fv, look) can be specified as: 

calculat e.desired.arm.posit ion(x , y ,y , cameras .enabled) 

float x,y,z; The location we want to look at*/ 

boolean cameras.enabledf] ; /*specifies cameras we may use*/ 

{ 

if (number.of .cameras .mobile (cameras.enabled) != 1) 
return (ERROR) ; 

else load ( where_the_camera_should.be (x,y ,z) , 

DESIRED. ARM. POSITION.TABLE) ; 
retum(OK) ; 

> 
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The translation mapping <r v (Cal, calibratejvision ) can be specified as: 

load.desired.arm.positions.f or_calibration() ; 
analyze =* Aanalyze.calibration.card.routine; 

The translation mapping a„(Find, Find) can be specified as: 

s etup. analyze. rout ine ( t ape_ cand , high.pr eci s ion) 
boolean high.precision; 
int tape. cand; 

< 

if (high.precis ion) { 

switch(tape.cand) of 

case strut: analyze .routine = 4find.strut_routine.hp; 

case node : analyze .rout ine = Af ind.node.routine.hp ; 

case obstacle: analyze .rout ine*4f ind.obstacle.routine hp; 

> 

> 

else 

switch(tape_cmnd) of 

case strut: analyze .rout ine » if ind.strut .rout ine; 

case node : analyze .rout ine =» 4find.node.rout ine; 

case obstacle: anal yze.rout ine = 4f ind.obstacle routine; 

> 

> 

> 

The translation mappings cr v (BMv , calibrate.vision) and <r v (BMv , look) ran be 
specified as: 

read_desired_arm_position() ; 

send_tape(dispatcher_socket , Insert .tape.immediate , Slave .Continue) 


The translation mappings cr v (FG , calibratejoision) and a v (FG, Find) ran be 
specified as: 


grab.frames(cameras.enabled) ; 


All other transitions are internal operations. 
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Figure 4.4: The Gripper Petri Net Transducer 

4.3.3 Petri Net Transducer for the Gripper Coordinator 

The Petri net model of the gripper coordinator in figure 4.4 consists of 7 places 
and 7 transitions. The transitions generally represent lower level routines, while the 
places represent the state of the system. The places and transitions axe specified as 
follows: 

Transitions: 

Start: Checks that the gripper is ready to run the next command. 

Cross: Checks the crossfire sensor, returning true or false. 
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GoP: Go Place closes the gripper to a desired width. 

MeP: Measure Place measures the size of the gripper opening. 

GoF: Go Force closes the gripper until the desired force is reached. 

MeF: Measure Force returns the force that the gripper is applying 
Next: Sends the token back if there is another command in the menu. 
Finish: Returns the token to wait for another command. 

Places: 

In: Input place. 

Out: The Output place. 

IS, OS: The input and output semaphores. 

Ready: Gripper Ready for the next command. 

BC: Before Command. 

AC: After Command. 

The subtasks to be processed by the gripper coordinator are T g = { crossfire , 
GoToPosition , GoToForce, M easure Position, M ensure Force} . The output al- 
phabet consists of hardware related operations for the gripper. 

The translation mappings for cr g the are: 

The translation mappings cr g (Cross . crons fire) can be specified as: 

crossf ire(){ 

if (data_from_crossf ire.sensors »» BLOCKED) return (TRUE) ; 
else retum(FALSE) ; 

> 

The translation mappings c g (GoP, GoToPosition) can be specified as: 
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goto_position(desired_position) ■( 

vri"te_val * calculate_controller_value(desired_position) , 
write_to_controller(write_val) ; 

if (vhatever_the_arror_condition3_are) return (ERROR) j 
else return. (OK) ; 

> 

The translation mappings <j 3 {GoF , GoToF orce) can be specified as: 
goto_f orce(desired_f orce) { 

write.val 3 calculate_controller_value(desired_f orce) ; 
vrite_to_controller(write_val) ; 

if (what ever _the_error_conditions_ are) retum(ERROR) ; 
else return. (OK) ; 

} 

The translation mappings <r g (MeP, MeasurePosition) can be specified as: 


measure_position() ; 


The translation mappings <r g (M tF , M easurtF otc&) can be specified as: 
measure.f orce() ; 

All other transitions are internal operations. 


4.3.4 The Petri Net transducer for the Arm Coordinator 

The Petri net model of the motion coordinator in figure 4.5 consists of 13 
places and 9 transitions. The transitions generally represent lower level routines, 
while the places represent the state of the system. The places and transitions are 
specified as follows: 

Transitions: 

Start:Checks that the User Program is ready to submit the next command. 
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Goto: Transition, for the goto(X, Y , Z) command. 

Ill: Illegal location for the arm to go to. 

Calc: Calculates the transform for the Cartesian command. 

Fin: The Arm has either reached the desired position or an error state. 

Que: The motion command is about to be put into the motion Queue. 

Mv: Start moving the arm. 

CSP: Calculate the next Set Point. 
t8: Motion Not yet Completed. 

Sta: Fired if in error state, or if the motion has been completed. 

Fin: Finished. Returns either ”OI\“ or ” Error”. 

Places: 

In: Input Place. 

Out: Output Place. 

IS, OS: The input and output semaphores. 

Ready: Motion system ready for the next command. 

PID: This represents the PID loop. 

Waiting: The user program is waiting until the lower levels of Kali output 
either the desired position, or ail error. 

Output: The Lower levels of Kali have either reached an error, or some 
position. 

LLR: A lower Level Ready, A token here indicated that the Queue is ready 
to begin the next job in the motion queue. 


Pi: Test for legality of path. 



P2: Ready to enqueue an item. 
TQ: Task Queued. 

NSP: Gets the Next Set Point. 
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The subtasks to be processed by the motion coordinator are £ m = {Approach, 
Move}. The translation mappings for the motion coordinator can be defined as 
follows: 

The translation mappings o m {Que, Approach ) can be specified as: 

set .Kali.mode (CARTESIAN) ; 
load_to_queue(desired_position) ; 

The translation mappings o m (Que, Move ) can be specified as: 

set .Kali.mode (JOINT) ; 
load.to.queue(desired.position) ; 

The translation mappings cr m {CSP, Approach) and <r m {CSP, Move ) can be spec- 
ified as: 

calculate.set.point (current .position, desired.position) ; 

Ail other transitions in the motion coordinator are interned. 

4.4 Analysis 

4.4.1 Structural Analysis 

The Dispatcher and all of the Coordinators are live, thus, the PNT underlying 
the whole coordination structure is live. Likewise, the net is structurally bounded. 
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4.4.2 Simulation 

Simulations are run to test the communication speed, when the message size 
and distances between the machines axe varied. The default setup is: 

Dispatcher Sol, a Sun 4/260, and the system file server, and network host. 

Motion Mars, a Sun 3/260. 

Vision Venus, a Sun 4/60 SparcStation. 

Gripper Earth a Sun 3/150. 

Timing of the speed was done by attaching a routine to every transition in 
the dispatcher, and recording the amount of time passed since that routine was last 
called. All of the times which measured the delay between sending a message and 
receiving one back were recorded. 

These tests were run with the initial tape: 

CalR , CalV , Move , Rel, Grip . Move , Approach , Rel , Look , Find , Move , Find , 
Move , Move , Approach. 

This results in 52 transitions being fired, resulting in 26 message transmission delays. 
4.4.2. 1 Message Size Variation 

This section tested the the variation in speed when the message size was in- 
creased. Under normal operations, sending a token involves the transmission of 8 
bytes, and a tape section is 12 to 40 bytes. In this test 50 and 500 bytes were 
appended to each socket message to see if this deteriorated the speed of the message 
transmission. 

The results of this variation can be seen in figure 4.6. As can be seen adding 
50 bytes didn’t affect the performance, while adding 500 bytes doubled the expected 


delav time. 








JO <7trwiV»y 
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Figure 4.7: Delay increases when sockets are used to communicate on 
a single machine. 

The message sizes were also varied with the computer configuration variation 
as described in the next section. 

4.4.2. 2 Computer Configuration Variation 

This section tested for variations in speed due to variations in the distances 
between the computers which were running the nets , and variations in how the 
computers were connected. 

All nets local In this test all of the nets were running on Sol, communicating, as 
normal, via sockets. The results of this can be seen in figure 4.7. 

The explanation for the counter-intuitive increase in delay time can be seen 
when one realizes that a computer only checks sockets every 200m,S, and since a 
computer will be synchronized with itself, (and is unlikely to be synchronized with 
another computer), a round trip socket communication on one computer takes twice 
as many clock cycles as communication between different computers. 
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Figure 4.8: There is no particular benefit to placing the Dispatcher on 
the file server. 

On peers In this we moved the dispatcher to Moon (a Sun 4/60GX SparcStation) 
to see if the dispatcher being the net server improved or worsened the situation. 

As can be seen from figure 4.8 there is no significant difference in communi- 
cation times, thus relieving any necessity of placing the dispatcher on the (possibly 
overloaded) file server. 

Non-local net The dispatcher was placed on pawl3.pawl.rpi.edu, a Sun3/50, lo- 
cated across campus. After testing this, the message size was increased by 50, then 
500 bytes. 

As can be seen from 4.6 the increased distance produced almost no changes 
in the normal and -)-50 byte tests, however when the amount of data transmitted 
gets larger, the increased distance produces a more pronounced effect. In fact, 
when the program was run with the display turned on (necessitating increased data 
transmission to allow the graphics) the program halted with lost data on 3 of the 4 
attempts. In further testing it was observed that more displays resulted in less time 
to failure. 
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Long distance The dispatcher was located on truebalt.caltech.edu, a Sun4 on 
based on a Sparc architecture, in Pasadena California- The coordinators were lo- 
cated on their normal computers, resulting in about 3000 miles of Internet commu- 
nication between the Petri nets. 

From figure 4.6 it can be seen that this increased distance resulted in degraded 
speed even with minimal data. The nets still ran (although more slowly) with 50 
extra bytes of data, even when displaying tull graphics, however the increase to 500 
extra bytes of data per socket transmission resulted in the net failing to complete 
the task every time (in 6 consecutive trys). The extra load was lowered to 200 bytes 
which resulted in success in 5 out of the 6 attempts. 




CHAPTER 5 

CONCLUSIONS AND FUTURE RESEARCH 
5.1 Summary and Conclusions 

This thesis stated the need for a software tool to assist in the development 
of distributed hierarchical systems. After a brief overview of Petri nets, available 
Petri net development tools, and available distributed program design tools it was 
seen that there were no tools which assisted with the distributed design task which 
allowed use of all the analysis tooks developed for Petri nets. Petri net transducers 
were introduced as a model which allowed a full analysis of the nets, and allow 
control of the transitions fired via a relatively simple mechanism. Because of this 
they were used as the basis of the TokenPasser program. 

With the criteria given, and the additional criteria requiring a friendly output, 
and the ability to attach routines to each transition (to allow the TokenPasser to 
develop code which could control more than a mere net), the Token passer program 
was developed. 

The coordination structure for an Intelligent Machine was identified as a 
project within the domain of the TokenPasser program, and after developing a Petri 
net model for the Dispatcher and Coordinators of a simple system, TokenPasser was 
used to develop code to simulate the nets on various machines. The code was then 
used to test several possible configurations, with respect to how those configurations 
affected the speed of communication. 

This testing allowed several facts to be discovered. 

1. Until verv large tokens are being passed, the size of the tokens doesn t affect 

the communication time. 

2. The longer the physical distance between the computers the smaller ’’very 
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large” is. 

3. A computer communicates (via sockets) more slowly with itself than with 
other computers. 

4. Being the file server, and network gateway don’t appear to influence commu- 
nication time. 

This thesis also, by developing a PNT for the Coordination Level, and develop- 
ing code to execute those nets, went one step further in justifying the Coordination 
theory for the Coordination level presented by Wang [25]. Taken together with the 
mathematical formulation for the Organization level, and well developed control 
theory for the Execution level, this further justifies a mathematical theory for In- 
telligent Machines. Such a mathematical theory will provide a solid foundation for 
the design, simulation, verification, and implementation of Intelligent Machines. 

5.2 Future Research and Modifications 

Some useful modifications, and additions to this code are: 

• Write program to translate GreatS PN .net files to TokenPasser input files. 
This will allow easier creation and modification of nets. 

• Modify to read .net files, instead of compiling net into code. 

• Write communication using Datagram protocol instead of SOCK_STREAM 
protocol. This should eliminate 200mS delay, at a cost of TokenPasser having 
to do it’s own data checking. 

• Modify the code to allow arcs which have a weight > 1. 

• Give the user a menu of valid commands to append to the tape or insert in the 
tape at any time, this can be done as on-screen buttons to allow telerobotic 
operations. 
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• Add in intermediate level 11 fast” command which allows a knowledgeable user 
to watch the progress of the net without the full overhead of a graphical 
display, (eg, the -semifast option results in no display except for printing out 
the number of each transition as it fires). 

• Rewrite the main routine to allow the user to define the communication among 
the nets in a more complex manner. Specifically, the current program only 
allows a two layers of communicating nets, (either a net connects to a pre- 
existing socket, or it opens a new socket, it can’t do both). If the main routine 
is rewritten to allow both opening and connecting to pre-existing sockets, this 
will allow the user to define a much more complicated net structure. 

• Rewrite to allow for partial display of graphics. Currently a fairly simple 
net fills the whole screen, it should be possible to mark certain transitions as 
” uninteresting” , allowing the display of a more interesting net by ignoring the 
trivial places or transitions. 
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APPENDIX A 
THE TokenPasser CODE 


A.l Compiling Instructions 

This is the makefile for the simulation described in this thesis. 

tt« 

## 

## 

## NOTICE OF COPYRIGHT 

## Copyright (C) Rensselaer Polytechnic Institute. 

## 1990 ALL RIGHTS RESERVED. 

»« 

## 

## Permission to use, distribute, and copy is granted ONLY 
## for research purposes, provided that thi3 notice is 
## displayed and the author is acknowledged. 

#« 

## This software is provided in the hope that it will be 
## useful. BUT, in no event will the authors or Rensselaer 
## be liable for any damages whatsoever, including any lost 
## profits, lost monies, business interruption , or other 
## special, incidental or consequential damages arising out 
## of the use or inability to use (including but not 
## limited to loss of data or data being rendered 

inaccurate or losses sustained by third parties or a 
## failure of this software to operate) even if the user 
## has been advised of the possibility of such damages, or 
## for any claim by any other party . 

## 

## This software was developed at the facilities of the 
tt Center for Intelligent Robotic Systems for Space 
tt Exploration, Troy, New York, thanks to generous project 
## funding by NASA. 
tt 

## Package: TokenPasser 
tt 

tt File: Makefile 
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«* 

## Written By: Michael Mittmamn 

## 

## Date: 1/30/91 

«« 

## Purpose : The purpose of the package can be found in the file 
## main . c . 

## This file contains the instructions to make 4 routines, 

## which model (by using a PNT) a coordinator controlling 
## an arm, vision system, and gripper. 

*« 

## Modification History: 

«* 

«# 

disp: draw.o main.o makePet.o petLib.o petri. o postn.o 
setup_disp.o \ 

transform. o sock_open.o menu.o window_manager . o read.socket .o 
cc -o disp draw.o main.o makePet.o petLib.o petri. o postn.o \ 
s tup_iisp.o transform. o menu.o window.manager . o \ 
scck.cpen.o read. socket . o -lm -1X11 

acm : iraw.o main.o makePet.o petLib.o petri. o postn.o setup arm.o 

\ 

transform. o sock.connect . o menu.o window.manager . o 
re-ic .socket . o 

cc -o arm draw.o main.o makePet.o petLib.o petri.o postn.o \ 
setup, crm.o transform.o menu.o window.manager .o\ 
cock.c_p.nect .o read.socket . o -lm -1X11 

vision, draw.o main.o makePet.o petLib.o petri.o postn.o 
setup. vision. o \ 

transform.o sock.connect . o menu.o window.manager . o 
r jad.socket . o 

cc -o vision draw.o main.o makePet.o petLib.o petri.o postn.o 

setup.vision.o transform.o menu.o window.manager. o\ 
sock.connect . o read.socket . o -lm -1X11 

grip: draw.o main.o makePet.o petLib.o petri.o postn.o 
setup.grip.o \ 

transform.o sock.connect .o menu.o window.manager . o 
read.socket . o 

cc -o grip draw.o main.o makePet.o petLib.o petri.o postn.o \ 


,1 


58 


setup -grip. o transform. o menu.o window .manager .o\ 
sock.connect . o read.socket .0 -lm -1X11 

window.manager . 0 : window.manager . c dumb.dec . h 
menu.o: menu.c pet.h 

draw.o: draw.c xhead.h pltr.h xdraw.h draw.li pet.h. dumb.dec.h 

main.o: main.c pet.h dumb.dec.h xdraw.h 

makePet.o: makePet.c pet.h dumb.dec.h 

petLib.o: petLib.c pet.h dumb.dec.h 

petri.o: petri. c pltr.h draw.h 

postn.o: postn.c pltr.h 

setup.disp . 0 : setup.disp. c pet.h pet2.h dumb.dec.h 
setup.grip . 0 : setup.grip. c pet.h pet2.h dumb.dec.h 
setup.arm.o: setup.arm.c pet.h pet2.h dumb.dec.h 
setup.vision.o : setup .vision. c pet.h pet2.h dumb.dec.h 
transform. o: transform. c pet.h pltr.h dumb.dec.h 
sock.open.o : sock.open.c pet.h dumb.dec.h 
sock.connect . 0 : sock.connect . c pet.h dumb.dec.h 
read.socket . o : read.socket .c pet.h dumb.dec.h 

A. 2 main.c 

This is the main routine. 


/* 

** 

** 

** 

** 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 
1990 ALL RIGHTS RESERVED. 


** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 



** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: main.c 
** 


** Written By: Michael Mittmann 

** Date: 1/30/91 

** 


** Purpose: The purpose of this package is to provide a facility 
** for translating petri net transducers into runnable code. 
When compiled with suitable net definition files 
(see setup_*.c) this package produces code that runs 
and displays a set of petri nets which communicate with 
each other via internet sockets. 

Further instructions, and examples can be found in the 
directory TokenPasser.doc. 


** 

** 

** 

m* 

** 

** 


** 


** 
** 
** 
** 
* * 
* 3*1 
** 
*3*t 


This file contains the main routine, which: 

1) determines if windows axe to be displayed. 

2) Sets up the windows. 

3) forks off a parent to moniter the windows 

3) calls the socket initilization routines 

4) calls the Petri net initilization routines 

5) goes into an infinite loop trying to fire 
transitions . 


** 


** Modification History: 

** 

*/ 


# include 
# include 
# include 
# include 
# include 


<signal.h> 
<stdio .h> 
<X11/Xlib.h> 
<X11/Xutil.h> 
"pet .h" 
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♦include "dumb.dec.h" 

♦include "xdraw.h" 

♦define Null Arc (-1) 

/* 

♦ These extems should all be declares in the setup _*.c files 
*/ 

extern in t num_trans it ions, number _of .sockets; 
extern struct transition world [] ; 
extern char title □ ; 

/♦ 

* This extern is declared in read_socket .c 
*/ 

extern int io.came; 

int graphics =* TRUE; /* are we doing graphics? ♦/ 

int should_pause * FALSE; /* are no transitions enabeled?*/ 

int redraw.screen - FALSE; /♦ User requested redraw? */ 


/* 

♦ Data structures needed for X-windows. 
*/ 

Display ^display; 

Window net .window; 

GC gc; 

unsigned long foreground, background; 


typedef struct { 


int 

place ; 

/* 

True if Place, False if Transition 

♦/ 

int 

used; 

/♦ 

True if this structure is valid 

♦/ 

int 

type; 

/♦ 

Indicates if State or Interaction Point ♦/ 

int 

tok ; 

/♦ 

Number of tokens 

*/ 

int 

in , out ; 

/♦ 

Number of input and output arcs 

♦/ 

int 

x, y; 

/♦ 

Grid Location in the Petri-Net window */ 

int 

party; 

/♦ 

Module number 

♦/ 

char 

♦name ; 

/♦ 

Name of Place 

♦/ 

char 

♦cond; 

/♦ 

Condition for Transition 

♦/ 

char 

♦code ; 

/♦ 

Action code for the transitions 

♦/ 

int 

priority; 

/* Priority of Transition 

♦/ 
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> pltrtype ; 
typedef struct { 


int 

used; 

/* 

True if this structure is 

used 

*/ 

int 

src ; 

/* 

Source pltr id for this arc 

*/ 

int 

dest ; 

/* 

Destination pltr id for this arc 

*/ 

int 

srcnext ; 

/* 

Arc id for the succeeding 

arc from src 

*/ 

int 

destnext ; 

/* 

Arc id for the succeeding 

arc to dest 

*/ 

int 

yO, xO, yl, 

x2, 

y3 , x4, y5 ; 




/* Effective Grid coordinates for the arc */ 

/* Arc goes through (xO,yO), (xO, yl) , (x2,yl), 

(x2, y3) , (x4, y3) , (x4, y5) */ 

int offO, off 1 , off 2, off 3, off4; 

/* Indicates the offset for each segment of the 
arc on the corresponding grid line */ 

} arctype; 

int npltr =140 , narc =140; 
pltrtype pltr[l40] ; 
arctype arc [140]; 

/* 

* redraw. signalO 

* called when a SIGUSR1 signal is sent (which happens when 

* the user requests a redraw. 

* 

* Arguments: None. 

* Returns : Nothing . 

* Requirements: The global variable redraw_screen . 


* */ 

void redraw, s ignal (M 
redraw_screen = TRUE; 

> 


/* 

* main(argv, argc) 

* 

* The main routine. It recieves as arguments acommand line 

* variables. The syntax is currently set up so that if 

* this is the main routine it has a usage of: 

* disp [-fast] 

* and if it is another routine it has a usage of: 

* <cmnd> <hostname> <socketnumber> [-fast] 
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* 

* This routine follows roughly this pseudocode: 

* if (fast option is given) Graphics * false; 

* if (Graphics) set up window; 

* if (Graphics) 

* { 

* forkO ; 

* if (process =* parent) run window monitoring loop; 

* else 

* { 

* initialize sockets; 

* initialize petri_nets; 

* create second type of PN data structure 

* figure out where the arcs should be placed; 

* sit in infinite loop trying to fire transitions; 

* > 

* > 

* 

* Arguments: argv, argc. (usage descibed above) 

* Returns : Nothing 

* Requirements: Xll library, System V enviroment , PF.INET 

* SOCK .STREAM sockets 


main ( argc , argv ) 
int argc; 
char **argv; 

{ 

int i,j ,good_token,pid,tran_count = 0; 

if (strcmp(title , "Dispatcher") == 0){ 
if ((argc < 1)1 I (argc > 2)K 
fprintf (stderr , "usage: */.s [-fast] \n" , argv [0] ) ; 
exit (1) ; 

> 

> 

else if (argc < 3){ 

fprintf (stderr , "usage: */.s <hostname><socketnumber> 
[<hostname><socketnumber> . . .] [-fast] \n" ,argv[0] ) ; 
exit (l) ; 

> 

if (strcmp("-fast" ,argv[argc-l] ) == 0) graphics = FALSE; 
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if (graphics) in.it .window () ; 

if (graphics && (pid*fork()) !» 0){ 

XMapRaised (display, net .window) ; 

event.reading.loop(pid) ; /* note that the program won't 

return 

* from this until the user hits q 

* in the window. 

*/ 

kill(pid.SIGKILL) ; /*kill child (laughing like a maniac)*/ 
XFreeGC (display , gc) ; 

XDestroyWindow(display , net .window) ; 

XCloseDisplay(display) ; 
exit (0) ; 

> 

else if (graphics) { 

/* signal to redraw screen */ 

signal (SIGUSR1, redraw. s ignal ) ; 

/* reset connection to server for display */ 
close(ConnectionNumber(display) ) ; 
if ((display * X0penDisplay("") )»» NULL) 
perror("f ailed XOpenDisplay in child:"); 

/* open or connect to the sockets (opening them doesn't use 
* argv or argc */ 

sock.start (argc , argv); 

/* define the net */ 
make.net () ; 

/* transform to seecondary data structure */ 
f ill.pltr.arc.map (world) ; 

/* mark initial conditions */ 

(void) initialize.markingO ; 

/* position the arcs */ 

for (i=0 ; i<narc;i++)arc_postn(i) ; 


/* dump on the screen */ 



drawQ ; 


/* the infinite loop */ 
while (TRUE) 

{ 

should.pause = TRUE; 

for (j *0; j< num.transitions ; j++) 

{ 

if (( good.token = transition_enabled_p(TRAN 
worldtj] ))) 

{ 

fire.transit ion (TRAN world [j] ,good_token) ; 
ref ill_places (FALSE) ; 

/* this line stops the */ if ( (++tran_count MAX_NUM_CYCLES) 

/* program at some number*/ ft&(strcmp(title, "Dispatcher") 

== 0 )) 

/* of iterations, delete for*/ exit .program () ; 

/* normal usage. */ 
should.pause * FALSE; 

} 

if (io.came) (void) io .handler (number.of .sockets) ; 
ref ill.places (FALSE) ; 

> 

if (redraw.screen) ref .screenQ ; 
redraw.screen = FALSE; 
if (should.pause) pause() ; 

> 

> 

else-( 

/* 

* We J re here iff we're not doing graphics. 

*/ 

/* open or connect to sockets */ 
sock_start(argc, argv) ; 

/* make the Petri net */ 
make.net () ; 

/* transform to the second data structure */ 
fill.pltr_arc.map (world) ; 


/* initialize the net */ 
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(void) initialize .marking () ; 

/* place all of the arcs */ 

for (i=0; i<narc;i++)arc_postn(i) ; 

/* start infinite loop */ 
while (TRUE) 

should.pause » TRUE; 
for (j =0; j< num.transitions ; j+-0 
{ 

if (( good.token * transition_enabled_p(TRAN 
worldCj] ) ) ) 

f ire_transition(TRAN worldCj] ,good_token) ; 

/♦This line stops the program*/ if ((++tran_count == 

MAX _NUM_ CYCLES ) 

/♦when 52 transitions have */ &&(strcmp(title, "Dispatcher") 

== 0 )) 

/* fired, remove for normal use */ exit_program() ; 

should.pause = FALSE; 

> 

if(io.came) (void) io_handler(number_of_sockets) ; 

> 

if (should.pause) pause() ; 

> 

> 

> 


/* 

* Author's note: 

* 

* running different sets of code depending on if graphics 

* is true or false is very ugly. This allows the 

* possibility of the net running differently if a 

* modification is made to one loop but not to the other. 

* 

* The only way I could see of fixing this was to put several 

* extra if statements into the loop. I didn't like this 

* solution, but given the fact that most of the delay comes 
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* from the socket communication, the effects of this 

* modification may be negligable. 


A. 3 draw.c 

This file contains the drawing routines. 


/* 

** 

** 

** 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 
1990 ALL RIGHTS RESERVED. 


** 

** Permission to use, distribute, and copy is granted ONLY 
** for research, purposes, provided that this notice is 
** displayed and the author is acknowledged* 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party . 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 


** File: draw.c 


** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
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** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains the routines associated with the 
** drawing and redrawing of the Petri net on the 
** Xwindow . 

** 

** Modification History: 

*/ 

/* 

* draw.c: 

* Handles all the drawing of Places/Transitions 

* /Arcs/Hilighting in the Petri-Met window. 

* */ 
♦include <stdio.h> 

♦include <math.h> 

♦include "xhead.h" 

♦include "pltr.h" 

♦include "xdraw.h" 

♦include ''draw.h" 

♦include ''pet.h" 

♦include l, dumb_dec .h" 


♦define MAX.PLACES 70 /* PUT IN INCLUDE FILE */ 

♦define FLASHTIME 150000 

extern int num_transitions ; 

♦define dMark 8 
♦define dArcAng 20 

♦define SIZE_RECT_X ((int) (Grids ize * 1.6)) 

♦define SIZE.RECT.Y GridSize 
♦define RECT.X 0 
♦define RECT.Y 0 

♦define Dia GridSize 

/ * 

* mag (x , off) Converts the Grid Coordinates to the real 

* coordinates on the screen, x is the grid number, off is 

* the offset on that grid. 

* */ 

♦define mag(x, off) ((x * GridSize + off * Off Size + GridOff)) 
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* draw() 

* Draws all the Places, Transitions and Arc3. 

* Also fills the places, and draws the "tape”. 

* Arguments: None 

* Returns : Nothing 

* Requirements: This requires an opened X-window, and filled 

* pltr , and arc data structures . 


void draw() 

{ 

int i ; 

for(i*0; i<npltr; i++) 
if CpltrCi] .used) { 
if (pltr[i] .place) 
dr_place(i) ; 
else 

dr_trans(i) ; 

> 

for(i 3 0; i<narc; i++) 
if (arc[i] .used) 
dr_arc(i) ; 
draw_tape() ; 
ref ill _places (TRUE) ; 

> 


/* 

* draw_tape() 

* Draws the menu tape . . 

* Note that it clears the area first, so that the words 

* aren't overwriting anything else and are legible. 

* Arguments: None. 

* Returns: Nothing. 

* Requirements: An open X~window, and the routines in menu.c 


void draw_tape() 

{ 

int i ; 



for(i*0;i<SIZE.MENU;i++) 

< 

draw.tape.box(i) ; 

> 

/* erase all previous arrows... */ 
st _ erase () ; 

f or (i=0 ; i<SIZE_MENU ; i++) 

{ 

XFillArcCdisplay, net .window, gc, SIZE.RECT.X/2 + 
i*SIZE_RECT_X, 

SIZE.RECT.Y, Dia/2 , Dia/2, 64*60, 64*240); 

> 

/* and draw an arrow pointing to the current menu selection */ 
st.normalO ; 

XFillArcCdisplay, net.window, gc, SIZE_RECT_X/2 + 
current .head.of .tape () 

* SIZE.RECT.X , SIZE.RECT.Y, Dia/2, Dia/2, 64*240, 64*60); 

> 

/* 

* draw.tape.boxC) 

* This draws an individual tape box. 

* Arguments: i, an integer specifying which box is to be drawn 

* Returns: Nothing. 

* Requirements : An open X window, and the routines in menu.c 

* 

void draw.tape.box(i) 

int i ; 

{ 

char *string; 
st. erase () ; 

XFillRectangleCdisplay , net.window, gc, RECT.X + 
i*SIZE_RECT_X, RECT.Y , SIZE.RECT.X, SIZE.RECT.Y); 
st.normal () ; 

XDrawRect angle (display , net.window, gc, RECT.X + 
i*SIZE_RECT_X , RECT.Y, SIZE.RECT.X, SIZE.RECT.Y); 
string* get.menu.string(i) ; 

XDrawString (display, net.window, gc, RECT_X+i*SIZE_R£CT_X, 
SIZE.RECT.Y /2, string, strlen(string) ) ; 

> 
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/* 

* dr.place(i) 

* Draws the place, stored in pltr[i] . 

* A Circle is drawn, with tokens inside and its name, 

* truncated to 5 chars is drawn next to the circle, along 

* with its id number (to be used in later verification.) 

* Arguments: i, an integer specifying which place to draw. 

* Returns: Nothing. 

* Requirements: An open X-window, and a filled pltr data 

* structure. 

* */ 

void dr_place(i) 

int i ; 

int x , y ; 

char name [ 10]; 

x * mag(pltr[i] .x, 0); 
y = mag(pltr[i] .y, 0); 

XDrawArc (display, net .window, gc, 
x - Dia/2 , y - Dia/2, 

Dia, Dia, 

0, 360 *64); 

sprintf (name , "y.2d:", i) ; 
if (pltr [l] .name != NULL) 
strncat (name , pltr [i] .name, 5); 

XDrawString (display , net .window, gc, 
x + 2*Dia/4, y, 
name, strlen(name) ) ; 

> 

/* 

* empty.place(i) 

* This routine draws a white filled circle in a place, 

* effectively erasing all of the tokens that were drawn there. 

* Arguments: i, an integer specifying which place to empty. 

* Returns : Nothing 

* Requirements: An open X-window, and a full pltr data structure 

* */ 




empty_place(i) 
int i ; 

{ 

int x , y ; 

x 3 mag(pltr [i] .x, 0); 
y 3 aag(pltrCi] .y, 0) ; 

st_ erase () ; 

XFillArc (display, net .window, gc, 
x-(Dia-2)/2 , y - (Dia -2)/2, 

Dia-2, Dia-2, 

0, 360 *64) ; 

st.normal () ; 

> 


/* 

* ref ill_places(new) 

* This routine draws tokens in the places. 

* 

* If new 33 TRUE then it redraws all of the tokens , otherwise 

* it only redraws the tokens in places where the number of 

* tokens has changed. 

* 

* This routine also takes care of redrawing the "tape" 

* 

* Arguments * A boolean specifying if all places which have 

* tokens are to be redrawn, or only the ones which 

* changed their number of tokens. 

* Returns : Nothing . 

* Requirements : An open X-window , a full pltr data structure, 

* and the routines in menu.c 


void ref ill.places (new) 
int new; 

{ 

static int has.tokens [MAX.PLACES] 3 {0}; /* record of # of 

tokens 

* in each place the 
last 
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* time this routine 
was 

* 

called . 

*/ 

static int last_head_position = 0; 
int i , j ; 
char *string; 

/* checking each place, redraw the tokens if needed */ 
for (i = 0; i < MAX_PLACES ; i ++ ) 

if (pltr [i+num_transitions] . used) 

if ( (has_tokens [i] < pltr [i+num_transit ions] .tok) I I 
new) 

{ 

empty_place(i+num_transitions) ; 
for (j = pltr [i+num_transitions] . tok; j >0 ; j — ) 
drawmark(pltr [i+num_transitions] .x, 
pltr [i+num_transitions] .y,j) ; 
has_tokens[i] = pltr[i+num_transitions] .tok; 

> 

else if ( (has_tokens [i] >pltr[i+num_transition3] .tok) I I 
new) 

{ 

empty_place(i+num_transitions) ; 

if ((has.tokens [i] = pltr [i+num_transit ions] .tok 
) ! = 0 ) 

for (j = pltr [i+num_trans it ions] .tok; j>0;j — ) 
drawmark (pltr [i+num_trans it ions] .x, 
pltr [i+num_transitions] .y,j) ; 

> 

> 

> 

/* if the pointer for the head of the tape has been incremented, 
redraw 
* the tape 
*/ 

if ((i* current _head_of _tape() ) 1 = last.head.position) 

{ 

st_erase() ; 

XFillArc (display , nex_window, gc, SIZE_RECT_X/2 + 
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last.head.position* SIZE_RECT_X , 

SIZE.RECT.Y, Dia/2, Dia/2, 64*240, 64*60); 
XFillRect angle (display, net .window, gc, RECT.X + 

last_head_position*SIZE_RECT_X +1 , RECT.Y +1 , 
SIZE.RECT.X -2 , SIZE_RECT_Y -2 ); 

st .normal () ; 

string* get_menu_string(last_head_position) ; 
XDrawString(display , net .window, gc, RECT.X+ 
last .head.posit ion*SIZE_R£CT_X , SIZE.RECT.Y /2 , 
string, strlen(string)) ; 

XFillArc (display , net .window, gc, SIZE.RECT.X/2 + i 
* SIZE.RECT.X, SIZE.RECT.Y, Dia/2, Dia/2, 
64*240, 64*60); 
last.head.position = i; 

> 

XFlush (display) ; 

> 


/* 

* angoff(x, ang) 

* (angle offset) is used to calculate to place the 

* tokens inside a place. 

* 

* Arguments: x, an integer specifying which token this is, 

* ang, the desired offset/token (in degrees) 

* Returns: A double spcifying how many radians off of the base 

* direction the token should be placed. 

* Requirements: M.PI is in math.h 

* 

double 

angoff (x, ang) 
int x , ang ; 

{ 

double res ; 

res = x * ang * M.PI / 180.0; 
return res ; 


> 






* drawmarkCx, y, n) 

* draws Nth. token at (x,y). Tokens are drawn in a 

* circular fashion inside the Place. The first token 

* is placed in the center, and the rest axe drawn in a 

* counterclockwise fashion, only one round. If too many 

* tokens are there, they may overlap. 

* 

* Arguments: x,y integers, specifying the location of the 

* place in which the token is to be drawn, n, an 

* integer specifying which token it i3. 

* Returns : Nothing . 

* Requirements: An open X window. 

* 

void drawmarkCx, y, n) 

int x, y, n; 

{ 

int xx , yy ; 

xx = mag(x, 0) ; 
yy = mag(y , 0) ; 
n— ; 

if (n !» 0) { 

xx += dMark * cos(angoff (n, 3*dArcAng)); 
yy -= dMark * sin(angoff (n , 3*dArcAng) ) ; 

> 

if (n>=0) 

XFillArc(display , net .window, gc , 
xx - dMark/ 2, yy - dMark/2, 
dMark , dMark , 

0, 360*64) ; 

> 

> 


/* 

* dr.trans(i) 

* Draws the transition (a horizontal line, followed 

* by its id) stored in "pltr[i]"; 

* 

* Arguments: i, an integer spcifying which transition. 

* Returns : Nothing . 
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* Requirements: An open X-window, and the pltr data structure. 

* */ 

void dr_trans(i) 

int i ; 

{ 

int x, y; 

char name [3] ; 

x = mag(pltr[i] .x, 0); 

y = mag(pltr[i] .y, 0); 

XDrawLine (display , net.window, gc, 
x - Dia/2, y, 
x + Dia/2, y) ; 

sprintf (name , "*/,2d:", i) ; 

XDrawString (display , net .window, gc, 
x + 2*Dia/4, y, 
name, strlen(name) ) ; 

> 


/* 

* dr_arc(i) 

* draws an arc, stored in arc[i] . The five segments 

* of the arc are drawn as straight lins. The Arrow mark 

* at the end of the arc is created as a small filled arc. 

* 

* Arguments: i, the number of the arc. 

* Returns : Nothing 

* Requirements: An open X-window, and the arc data structure. 

* */ 

void dr_arc(i) 
int i ; 

{ 

XPoint 1 [6] ; 

1[0] .x = mag( arc[i].xO, arc[i].offO ); 
l[0].y = mag( arc[i].yO, 0 ); 
if (pltr Care [i] . sre] .place) 

ICO] .y +* Dia/2; 
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1[1] .z = 1[0] .x; 

1 Cl] - y = mag( arc[i].yl, arc[i].offl ); 

l[2].x = mag( arc[i].x2, arc [i]. off 2 ); 

1 [2] .y = 1 [1] .y; 

1 [3] .x = 1 [2] .x; 

l[3].y » mag( arc[i] .y3, arc [i] . off 3 ); 

1[4] .x = mag( arc[i] .x4, axc[i].off4 ); 

1 [4] .y = 1 [3] .y; 

1 [5] .x = 1 [4] .x; 

l[5].y = mag( arc[i].y5, 0 ); 

if (pltr[arc[i] .dest] .place) 

1 [5] .y -= Dia/2 ; 

XDrawLines (display , net.window , gc, 

1, 6, CoordModeOrigin) ; 

XFillArc (display , net .window , gc, 

1 [5] .x-Dia/4, 1[5] .y-Dia/4, 

Dia/2, Dia/2, 

(45) *64, 90*64); 

} 

/* 

* A routine used to hilight a place or transition for a 

* short time, then unhilight it. Note, for some reason 

* GXinvert works, while GXxor doesn't. 

* 

* Arguments: i, the number of the transition 

* Returns : Nothing 

* Requirements: The pltr data structure, and an open X-window 

* */ 

void flash.pltr (i) 

int i ; 

int x ,y ; 

XSetFunct ion(display , gc, GXinvert); 

= mag(pltr [l] .x, 0) ; 


x 




y » mag(pltr[i] .y, 0) ; 

XFillArc (display, net .window, gc, 
i - Dia/2 , y - Dia/2, 

Dia, Dia, 

0, 360 *64) ; 

XFlush (display) ; 

usleep( (unsigned) FLASHTIME) ; 

XFillArc (display, net .window, gc, 
x - Dia/2 , y - Dia/2, 

Dia, Dia, 

0, 360 *64) ; 

XFlush(display) ; 

XSetFunct ion(display , gc, GXcopy) ; 

> 


/* 

* st.eraseO 

* changes the foreground to white so that anything 

* can be overwritten. 

* 

* Note that this is being used because 

* XSetFunction(display , gc, GXClear) ; didn't seem to work.. 

a 

* Arguments: None 

* Returns : Nothing 

* Requirements: The display data structure. 

* 

void st.eraseO 

{ 

XSetForeground(display , gc, 

Whit ePixel (display , Def aultScreen (display) ) ) ; 

> 

/* 

* st.normalO 

* (set normal mode), undoes the effect of st.erase, if 

* used earlier. Using st .normal multiple times should 

* not cause any harm. 
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* Argument s : None 

* Returns : Nothing . 

* Requirements: The display data structure. 

. ■•/ 

void st_normal() 

{ 

XSetForeground (display , gc, 

BlackPixel (display ,Def aultScreen(display) ) ) ; 

> 

/* 

* void ref.screenQ 

* Redraws the whole screen. 

* 

* Arguments: None 

* Returns : Nothing 

* Recuirements: The display and net .window data structures. 


void raf .screenO 

XCV - urWindov (display, net .window) ; /* clears the petri-net 

win ow */ 
dra Q ; 

> 


A. 4 r ikepet.c 

T i file contains the routines needed to produce the data structures defining 

net. 


/* 

** 

** 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 
1990 ALL RIGHTS RESERVED. 


** 

** 

** Permission to use, distribute, and copy is granted ONLY 
-* for research purposes, provided that this notice is 
displayed and the author is acknowledged . 


« This software is provided in the hope that it will be 



a 
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** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party . 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: makePet.c 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains routines to fill the data structures 

** defining the net. 

** 

** Modification History: 

** 

*/ 

# include <varargs.h> 

^include <sy s/types ,h> 

#include <sys/t imeb . h> 

^include "pet . h" 

#include "dumb. dec .h M 

extern int sock.sendQ ; 

extern struct transition world [] ; 

extern struct place.ptr place.ptr. array □ I 
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extern int menu[] ; 



* place_place() 

* This routine is used to declare the location of a place 

* on the graphic display . . . 

* 

* Arguments: place_num, an integer specifying a place. 

* x_loc, y_loc, the locations on the screen. 

* Returns : Nothing 

* Requirements: None. 

* 

void place_place(place_num ,x_loc , y_loc) 

int x_loc, y_loc ,place_num; 

{ 

if ((x_loc % 2 » 1) I I (y_loc y, 2 == 1)) 

printf ("warning the location of place y£d is odd 
\n" ,place_num) ; 

place_ptr_array Cplace_num] .x_loc = x_loc; 
place_ptr_array [place_num] .y_loc = y_loc; 

> 




* identity (value) 

* this is the default routine used for the coloration 

* and decoloration of tokens. It doesn't change the 

* token value . 

* 

* Arguments : value: and integer. 

* Returns: value: the same integer. 

* Requirements: reflexive identity property. 

* — — ** 

mt ident ity (value) 

int value; 

{ 

return (value) ; 

} 

/* 

* initialize. transition^ cn.ptr , imt_tran,x_loc , y.loc) 

* 

* This function points both the preplaces and the 




* post places of a transition to NULL, and points 

* the transition to the function specifies in the call* 

* 

* It should be called with a call like: 

* initialize.transition (function_name, pointer_to_transition) ; 

* 

* Arguments: fcn_ptr: a pointer to the function which 

* the transition fires. 

* init_tran: a pointer to the transition 

* being initialized. 

* x_loc , y.loc, the x and y screen locations. 

* Returns: Nothing 

* Requirements: The obvious. ^ 

void initialize_transition(f cn_ptr , mit_tran,x_loc , y_loc) 

int (*fcn_ptr) () ; 

struct transition *imt_tran; 

init_tran->routine * fcn.ptr; 
init_tran->pre_places = NULL; 
init_tran->post_places = NULL; 
init_tran->enabled_by * NULL; 
init_tran->menu_requirements * NULL; 
init_tran->consumes_menu * TRUE; 
if ((x_loc '/. 2 == 1) II (y_loc 7,2 » l)) 
printf ("warning the location of transition %d is odd\n" 

, mit.tran - 4(world[0] ) ) ; 
init_tran->x_loc = x_loc; 
init_tran->y_loc = y_loc ; 


> 


/* 

* void add_pre_list (va_alist ) 

* 

* This function should be called with a call like: 

* add_pre_list(Jt(transition.pre_place) , Aintl, &int2 .NULL); 

* to add integers inti and int 2 to the precursor list for 

* transition 

* (note transition is a data structure- of type- transition) 




* this takes a pointer to a transition, and a list of 

* pointers to integers and forms a linked list of pointers 

* to integers starting with, the pointer pre_places in the 

* specified transition. 

* For some clarification see varargs(3), vhich will clarify the 
variable 

* number of arguments... 

* 

* Arguments: a list of pointers as described above. 

* Returns : Nothing 

* Requirements: Link in var_args.h 

* */ 

void add.pre.list (va.alist) 

va_dcl 

{ 

va_list pointer; 

struct pre_pointer *new_place, **old_place; 
struct place.ptr *place_header ; 

va_start (pointer) ; 

old.place = va_arg (pointer, struct pre.pointer **) ; 

while ( (place_header*va_arg(pointer, struct place.ptr *)) !* 

NULL) 

{ 

new_place = (struct pre.po inter *) 

malloc(sizeof (struct pre_pointer) ) ; 
if (new_place == NULL) 

{perror ("add.preplace rmalloc : " ) ; 
exit (-1) ; 

> 

new_place->place = place_header ; 
new_place->next_place = NULL; 

new_place->decoloration. routine = identity; 

♦old.place = new_place; /* point the 

previous */ 

old.place = £(new_place->next .place) ; 

/*new_place->next .place*/ 

> 

place*/ 

va_end(po inter) ; 


/* at the current 
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/* 

* add.post.list (va.alist) 

* This function should be called with a call like: 

* add_post_list(4(transition.post_place) ,4intl,rvl , 

* 4int2,rv2,4int3,rv3,NULL) ; 

* to add integers inti int2 and int3 to the post 

* list for transition 

* (note transition is a data structure of type 

* transition, and rv are integers which * 0 if the 

* data is local, and = the socket number where the 

* data belongs if the data isn't local.) 

* 

* this takes a pointer to a transition, and a list of 

* pointers to integers and forms a linked list of pointers 

* to integers starting with the pointer post .places in the 

* specified transition. 

* For some clarification see varargs(3) , which will clarify the 
variable 

* number of arguments. . . 

* 

* Arguments: a list of pointers as described above. 

* Returns : nothing 

* Requirements: Include var.args.h 


void add_post_list (va.alist) 
va.dcl 

va.list pointer; 

struct post.pointer *new_place, **old_place; 
struct place.ptr *place_header ; 

va.start (pointer) ; 

old.place * va_arg(pointer , struct post.pointer **) ; 

while ( (place_header= va_arg(pomter , struct place.ptr *)) ! - 

NULL) 

{ 

new.place = (struct post.pointer *) 

malloc(sizeof (struct post.pointer)); 
if (new.place == NULL) 

{perror ("add.postplace :malloc: ") ; 
exit (-1) ; 

> 




new_place->remote * va_arg (pointer , int) ; 
nev_place _ >place 3 place_header; 

aew_place->coloration_routine 3 identity; 
new_place->data_trans_routine = sock_send; 
new_place->next_place = NULL; 

*old_place 3 new.place; /* point previous to 

*/ 

old.place 3 4(nev_place->next_place) ; /*this one 

*1 ' 

y 

va_ end (pointer) ; 

> 




* instruct _in_menu_p(trans) 

* 

* this routine checks to see if there is a list of 

* "menu" commands which axe required for the 

* transitions to be fired. If the transition requires 

* a menu command, this routine goes through the list 

* of possible enabling commands , and checks to see if 

* any of them match the current command. 

* 

* Arguments: a pointer to the transition to be checked. 

* Returns : True/False 

* Requirements: the routines in menu.c 

* 

int instruct_in_menu_p(trans) 

struct transition *trans ; 

{ 

int men_val; 

struct enabelors *cur_menu_allowed; 

if (trans->menu requirements == NULL) 
return (TRUE) ; 

if ((men_val 3 get_menu_value() ) 33 NO_MENU_CMND) 
return(FALSE) ; 

for (cur_menu_allowed= trans->menu_requirements ; 
cur_menu_allowed ! = NULL ; 

cur_menu_allowed 3 cur_menu_alloved->next_enabelor) 

{ 

if (cur_menu_allowed->enabelor 33 men_val) 
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return (TRUE) ; 

> 

return (FALSE) ; 

> 

/* 

* add_token(place_num, data) 

* 

* This routine adds a token to the list of tokens attached 

* to a place, and calls a routine that adds one to the 

* number of tokens in the pltr represnetation . 

* 

* Arguments: place.num: integer declareig vhaigh place 

* gets the token. 

* data: integer = the value of the token. 

* Returns : Nothing . 

* Requirements: the pltr and normal data structures. 

* 

void add_token(place_num, data) 

int data, place_num; 

struct place.contains *newplace, *temp; 

if ((newplace a (struct place_contains *) 
malloc(sizeof (struct place.contains) ) ) *= NULL) 

perror("add_token:malloc: ") ; 
exit (0) ; 

> 

temp » place_ptr_array [place.num] .place; 
place_ptr_array [place.num] .place =newplace; 
newplace->ob j ect = data; 
nevplace->next_contents = temp; 

/* putting tokens in the drawing representation.... */ 

(void) add_tok_in_pltr_rep(place_num) ; 

> 



* remove_token (place.num, data.trans ,decoloration_routine) 

* 
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* This routine searches through the data in place place_num, 

* and if either: 

* it can find a token such that: 

* decoloration_routine(token) " data 

* or: 

* the transition is enabeled by any token, and it 

* finds a token. 

* It removes that token, and returns OK. 

* If this somehow fails, the routine returns an error. 

* 

* Arguments: place_num: the place which has the token. 

* data: the value of the token to be removed. 

* trains: the transition which may have an 

* enabeling requiremment . 

* decoloration. rout ine : a pointer. 

* Returns : QK/ERRQR 

* Requirements: Just all of the data structures. 

* ... — / 

remove .token (place.num, data.trans .decoloration.routine) 

int data, place.num; 

struct transition *trans; 

int (♦decoloration.routine) () ; 

< 

struct place .contains *current , **previous; 
int any.data; 

any.data = (trans->enabled_by == NULL) ; 
previous = (struct place.contains ♦*) 

&(place_ptr_array [place.num] ) ; 

for (current = place.ptr.array [place.num] .place; current != 
NULL; 

current = current->next_contents) 

{ 

if (decoloration.routine !- NULL) 

{ 

if ((data == 

(♦decoloration.routine) (current->object) ) I I 
any.data) 

♦previous = current->next .contents ; 
free ((char ♦) current); 

(void) remove_tok_in_pltr_rep(place_num) ; 
retum(OK) ; 




> 

else previous 3 k ( current ->next_ content 3 ) ; 

> 

else 

< 

if ((data == current->obj ect) I I any.data) 

♦previous = current ->next .contents ; 
free ((char ♦) current); 
remove_tok_in_pltr_rep(place_num) ; 
return (OK) ; 

> 

else previous = k ( current ->next .contents) ; 

> 

> 

return (ERROR) ; 

> 


/* 

♦ declare_enab_tokens (va.alist) 

* 

♦ This is a function which declares either the menu value 

♦ required to fire a transition, or the token values 

* required to fire a (colored) transition. 

* 

♦ This function should be called with a call like: 

♦ declare_enab_tokens (transit ion _ > (whichever) , inti, 

♦ int2 ,int3, NULL); 

♦ to add integers inti int2 and int3 to the enabelor list 

♦ for transition 

♦ (note transition is a data structure of type transition) 

♦ ((whichever) is either enabeled.by or menu.requirements) 

♦ 

* this takes a pointer to a enabelor and a list of pointers 

* to integers and forms a linked list of pointers to integers 

* starting with the pointer enabelor in the specified 
transition. 

* For some clarification see varargs(3), which will 

* clarify the variable number of arguments... 

* 

* Arguments: a list of pointers as described above. 

* Returns : nothing 
Requirements: Include var.args.h 


* 
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void declare.enab .tokens (va.alist) 
va_dcl 
{ 

va.list pointer; 

3 tmct enabelors *new_one, **old_one; 
int enab .tokens ; 

va_ start (pointer) ; 

old.one* va.arg (pointer, struct enabelor3 **) ; 
while ( (enab_tokens*va_arg(po inter, int )) != NULL) 

{ 

new_one= (struct enabelors *) 

malloc(sizeof (struct enabelors)); 
if (new.one == NULL) 

{perror ("declare_enabelor_tokens:malloc:") ; 
exit (-1) ; 

> 

new_one->enabelor* enab .tokens ; 
new.one- >next_enabelor= NULL; 

♦old.one* new.one; /* point the previous 

*/ 

old.one- 4 (new_one->next_enabelor) ; 

/*new_place->next .place*/ 

y /* at the current 

place*/ 

va.end (pointer) ; 

> 

/* 

* f ill.post_pntr(place , tran, data.trans, coloration) 

* 

* This routine puts some addional information into the 

* the post .pointer between the given place and transition. 

* 

* This is used for declaring a particular data.trans it ion 

* routine (other than the default (sock.send) or a 

* coloration routine. 

* 

* Arguments: place, tran: integers referring to the place 

* and transition which need the infiormation attached. 

* date.trans, coloration, the routines which 

* will get attached. 
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* Returns: True/False (depending on sucess) 

* Requirements: Just the data structures. 

* */ 

int fill.post.pntr (place , tran, data.trans, coloration) 

int place, tran; 

int (*data_trans) () , (^coloration) () ; 

{ 

struct post_pointer *temp; 
int sucess ; 

sucess * FALSE; 

for (temp = world [tran] .post .places; temp != NULL; 
temp - temp->next_place) 

if ((temp->place - 4place_ptr_array [0] )== place) 

{ 

temp->data_trans_routine = data.trans; 
temp->coloration_routine = coloration; 
sucess = TRUE; 

> 

> 

retum(sucess) ; 

> 

/* 

* fill.pre.pntr (place , tran, coloration) 

* 

* This routine puts some addional information into the 

* the pre.pomter between the given place and transition. 

* 

* This is used for declaring a particular coloration routine. 

* 

* Arguments: place, tran: integers referring to the place 

* and transition which need the infiormation attached. 

* coloration, the routines to be attached. 

* Returns: True/False (depending on sucess) 

* Requirements: Just the data structures. 

* */ 

int f ill_pre_pntr (place, tran, coloration) 

int place, tran; 
int (^coloration) () ; 

{ 

struct pre.po inter *temp; 
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int sucess; 

3UC9SS 3 FALSE; 

for (temp * world [tran] .pre_places ; temp !=* NULL; 
temp 3 temp->next .place) 

{ 

if ( (temp->place - ftplace.ptr.array[0] )==place) 

< 

temp->decoloration_routine 3 coloration; 
sucess 3 TRUE; 

> 

> 

return (sucess) ; 


A. 5 menu.c 

This file contains the routines needed to control and manipulate the “tape”. 


/* 

** 

** 

** 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 
1990 ALL RIGHTS RESERVED. 


** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** 7h.is software is provided in the hope that it will be 
* 3 useful. BUT, in no event will the authors or Rensselaer 
33 be liable for any damages whatsoever, including any lost 
33 profits, lost monies, business interruption, or other 
33 special, incidental or consequential damages arising out 
33 of the use or inability to use (including but not 
33 limited to loss of data or data being rendered 
33 inaccurate or losses sustained by third parties or a 
33 failure of this software to operate) even if the user 
33 has been advised of the possibility of such damages, or 
33 for any claim by any other party . 

3 « 

This software was developed at the facilities of the 




** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: menu.c 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 

** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains the routines to manage the "tape 11 

** for the PNT 

** 

** Modification History: 

** 

*/ 

# include "pet.h" 
extern int menu[] ; 
int head * 0 ; 
int tail = 0 ; 

/* 

* get .menu. string (menu. slot. number ) 

* This routine returns a string associated with the tape 

* command in tape location menu. slot. number . 

* 

* Arguments: menu. slot number, an integer, specifying 

* which menu slot. 

* Returns: a character string associated with the command 

* in that slot . 

* Requirements: none. 

* ~ 

char *get .menu, string (menu.slot .number) 

int menu. slot .number; 

{ 

static char *menu_strings G “{"empty ",/* Note that this list 
should */ 

"CalR ",/* be in the same order 




as 


*/ 


"Move 


"Approa 

II 

"CalV 

II 

1 

"Grip 

It 

J 

"Rel 

II 

» 

"MeaFo 

II 

> 

"GoFor 

II 

y 

"MeaPo 

if 

j 

"GoPos 

H 

t 

"Cross 

li 

y 

"Retur 

il 

y 

"Look 

li 

i 

"Find 

li 

» 

"Conti 

il 

i 

"Slave 



in pet.h */ 


return (menu. strings [menu [menu.slot.number] ] ) ; 

} 


/* 

* current .tail. of .tapeQ 

* This routine esists in case anyone needs to know if 

* new co mman ds have been written to the tail of the tape. . 

* 

* Argument s : none 

* Returns : integer location of tail. 

* Requirements: none 

* — — — — 

int current .tail. of .tape () 

{ 

retum(tail) ; 

} 


/* 

* current .head. of .tape 

* This routine is normally used so that outside routines 

* can tell if tape commands have been removed. 

* 

* Arguments :none 

* Returns: integer specifying location of head of tape. 

* Requirements: none 




int current_head_of _tape() 

{ 

return (head.) ; 

> 


/* 

* get_menu_value() 

* This returns the value of the command currently at 

* the head of the tape 

* 

* Arguments: none 

Returns : int. value of command at head of tape, or error. 

* Requirements: none 

* * 

int get _menu_ value () 

< 

if (head != tail) 
return (menu [head] ) ; 
return (NO _MENU_CMND ) ; 

> 


/* 

* insert _menu _ c ommand_ immedi at e ( cmnd ) 

* This inserts the tape command cmnd at the head of 

* the tape, moving all of the other commands back one slot. 

* 

* Arguments: cmnd, tthe integer value of the new command 

* Returns: ERRQR/QK 

* Requirements: conservation of momentum. 

* 

insert _menu_ cmnd _ immedi at e (cmnd) 

enum tape_cmnd cmnd; 

if (((tail+l)?. SIZE.MENU) == head) return (ERROR); 
head = (head-l+SIZE_MENU)XSIZE_MENU; 
menu [head] = (mt)cmnd; 
retum(OK) ; 

> 


/* 

* add_menu_cmnd (cmnd) 
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* This places cmnd at the tail of the co mm a n d tape. 

* 

* Arguments : cmnd, the integer value of the nev command. 

* Returns : ERRQR/OK 

* Requirements: none. 

* */ 

add _ menu _ cmnd ( cmnd ) 

enum tape_cmnd cmnd; 

if (((tail+l)X SIZE_MENU) = head) return (ERROR); 
menu [tail] = (int)cmnd; 
if (++tail == SIZE.MENU) tail = 0; 
return (OK) ; 

> 


/* 

* increment _menu_ptr() 

* Thi3 command increments "head" to the next command. 

* The option of not doing this for any tape command 

* exists because as Fei-Yue describred the PNT, using 

* a tape command doesn't necessarally increment you to 

* the next command. 

* 

* Argument 3 : none 

* Returns :Error/ok 

* Requirements: none 

* */ 

increment _menu_pt r ( ) 

{ 

if (tail == head) return (ERROR) ; 
menu [head] = (int) Empty; 
if (++head == SIZE.MENU) head=0 ; 
return (OK) ; 

> 


A. 6 petLib.c 

This file contains most of the routines which are used in the manipulation of 
the Petri net. (eg. all the routines for firing the transitions...) 
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/* 

** 

** 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 


** 1990 ALL RIGHTS RESERVED. 

4*4* 

4*4* 

*41 Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
* * limited to loss of data or data being rendered 
4c 4c inaccurate or losses sustained by third parties or a 
4 c 4 c failure of this software to operate) even if the user 
4 c * has been advised of the possibility of such damages, or 
4 c 4c for any claim by any other party. 

4c 4c 

4 c 4 c This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
4 c 4c Exploration, Troy, New York, thanks to generous project 
4c 4c funding by NASA. 

4c 4c 


4c4c Package: TokenPasser 

4C 4c 


4c4t File: petLib.c 

4c 4c 

4c 4* Written By: Michael Mittmann 

4t4c 

*4c Date: 1/30/91 


4c 4c 

4 c 4 c Purpose : The purpose of the package can be found in the file 
4*4c main.c. 

4 * 4 c This file contains routines used to manipulate the 

4 c 4c Petri nets (eg, fire transitions, check for enabeled 

4*4c transitions) 


4c 4* 

4*4* Modification History: 


4c 4c 
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*/ 


♦include <varargs.h> 

♦include <sys/types .h> 

♦include <sys/t imeb . h> 

♦include <stdio .h> 

♦include "pet . h" 

♦include "dumb. dec .h" 

extern struct place.ptr place.ptr.array G ; 
extern struct transition vorld[] ; 
extern int graphics; 
extern char title G ; 

/* ********************************************************* 

* A routine used in timing. 

* the input "old" is a boolean which is true if the 

* function has been called before, and false if it has not. 

* 

* the value returned is the number of milliseconds since 

* this routine was last called. 

* 

* Arguments : old: a boolean. 

* Returns : the integer number of milliseconds passed since 

* the routine was last called. 

* Requirements: timeb.h 

* ********************************************* ************/ 

int time.diff Cold) 
int old; 

{ 

static time.t seconds = 0; 
static unsigned short millisec 3 0; 

struct timeb space; 

int ret .value; 

ftime(&space) ; 

if (oldH 

ret. value 3 1000*(space. time-seconds) + 

(space .millitm-millisec) ; 
seconds 3 space. time; 
millisec 3 space .millitm; 
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return (ret .value) ; 

> 

else { 

seconds 3 space. time; 
millisec 3 space. millitm; 
return (-1) ; 

> 

> 

/* **************************************************** 

* This routineis called repeatedly to save the time 

* difference between the last time time.diff was called. 

* 

* Arguments: none 

* Returns : 1 

* Requirements: timeb.h 

int time.holder.l [1000] ; 
int rec.timelO 
{ 

static int arr_counter 3 0 ; 
static int first.call 3 TRUE; 

if (first .call ) i 
first.call 3 FALSE; 
time.diff (FALSE) ; 

> 

else time.holder.l [arr_counter++] 3 time.diff (TRUE) ; 
return (l) ; 

> 

/* ********************** 33333 * 3 ******** 3 ************** 

* This routineis called repeatedly to save the time 

* difference between the last time time.diff was called. 

* 

* Arguments: none 

* Returns : 1 

* Requirements: timeb.h. 

* *********************************************★*******/ 

int t ime_holder_2 [1000] ; 
int rec_time2Q 
{ 

static int arr_counter^O ; 




time_holder_2[arr_counter+-t-] * time.diff (TRUE) ; 
return (1) ; 

> 

/* ******* ********************************************** 

* This routine prints out the time.diff numbers to a file 

* then exits the program. 

* 

* Arguments: none 

* Returns : none 

* Requirements : none 

* ***************************»***********************♦♦*/ 

void exit .program () 

{ 

int i ; 

FILE *fp ; 

fp = f open("outl" , "w"); 
for (i=0 ; i<MAX_NUM_CYCLES/2; i++) 
fprintf (fp , "%d \n" ,time_holder_l [i] ) ; 
f close(fp) ; 

fp = f open("out2" , "w") ; 
for (i=0 ; i<MAX_MUM_CYCLES/2; i++) 
fprintf(fp, "/(d \n" ,time_holder_2 [i] ) ; 
fclose(fp) ; 
printf ("f inish\n") ; 
exit(l) ; 

> 

/* ****** * ***** ****** ********** *** **************** *** ***** 

* this function sends a message over the specified socket. 

* the message is the characters specified in the 

* definition of PLAC (currently ,, pla ,, followed by the 

* integer array_num. Upon reception the reader decodes 

* PLAC to realize that the following integer is the place 

* in an array that must be incremented. 

* 

* Arguments: Socknum, the integer number of the socket 

* the message is to be transmitted over. 

* array_num: the number of the place in the 

* dest inat ion net . 

* token_val: the value of the token to be sent. 
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* Returns : 1 

* Requirements: 30cknum is an opened socket. 

int sock_send(socknum, array_num , token.val) 
int 3ocknum, array.num, token.val ; 

{ 

int buf [9 + (sizeof JUNK) /sizeof (int)] ; 

buf [0] = (int) PLAC; 
buf[l] =* array _num; 
buf [2] = token_val; 
buf [3] = (int) DATA; 
buf [4] = sizeof JUNK; 
strcpy (&buf [5] , JUNK) ; 

if (write (socknum, (char *) buf, 5*sizeof (int)+ sizeof JUNK) 

< 0 ) 

perror("client :write:") ; 
retum(l) ; 

> 

/* ******************************************************** 

* This function should be called with a call like: 

* send_tape (socket .number , command.num, tape.cmndl, 

* tape_cmnd2, tape_cmnd3, NULL); 

* to send those three tape commands over the socket socket.number 

* 

* For some clarification see varargs(3), which will 

* clarify the variable number of arguments... 

* 

* Arguments: socket .number is the number of the socket. 

* command.num is one of the enum type 

* tape commands described in pet.h 

* tape.cmnd. . are one of the enum type 

* tape commands described in pet.h. 

* Returns : nothing 

* Requirements: var.args.h, socket .number is an open socket. 

* *************»**:*»< mat* **************************** ******/ 

void send.tape(va.alist) 
va.dcl 

va.list pointer; 

int buf [SIZE.MENU+9 + (sizeof JUNK)/sizeof (int)] ; 
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int sock.num, tape.cmnd , command count^O , command rmm; 

va_ start (pointer) ; 

sock_num = va_arg(pointer , int) ; 

command. num = va_arg(pointer , int) ; 

while ( (tape_cmnd=va_arg (pointer , int )) ! = NULL) 

{ 

buf[l+ ++comm and. count] * tape.cmnd; 

> 

buf[Q] = command.num; 
buf[l] » command.count ; 

if (co m ma n d.count > SIZE.MENU) printf("to many commands, 
sending anyway, but fix this, or you’ll get 
a segmentation fault next time.... \n"); 
buf [command.count + 2] = (int) DATA; 
buf [command.count + 3] = sizeof JUNK; 
strcpy (&buf [command.count + 4] , JUNK) ; 

if (write (sock.num, (char *) buf, (command.count + 
4)*sizeof (int) 

+sizeof JUNK) < 0) 
perror(" client : write : ") ; 
va.end(pointer) ; 

> 


/ * ******************************************************** 

* A predicate which determines if a transition is enabled, 

* returning either true or false. 

* 

* Arguments: tran: a pointer to a transition. 

* Returns: FALSE/ value of the legitimate token. 

* Note: this is a bug: one can't have 0 (== FALSE) 

* as a token value. 

* Requirements: all the normal data structures. 

* ******************************************************** j 

int transition.enabled.p (trans) 
struct transition *trans; 

{ 

struct pre.pointer *next ; 

int result = FALSE, carry.val .possible.value; 
struct enabelors ♦allowed; 
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struct placa_contaias *item; 


if (trans->pre_places *= NULL) return (FALSE) ; 
if ( instruct _ in_menu_p (traas ) ) 

{ 

for (allowed = trans->enabled_by ; allowed != NULL; 
allowed = allowed->next_enabelor) 

{ 

carry_val = TRUE; 

for (next = trans->pre_places ; next != NULL; 
next = next->next_place) 

{ 

result = FALSE; 
if (next->place != NULL) 

{ 

for (item = next->place->place ; item != 

NULL;item= item->next_contents) 

{ 

if ((*next->decoloration_routine) (next->place->place->object) !* 
allowed->enabelor) 

{result = result II FALSE;} 

else 

{result 3 TRUE;} 

} 

} 

carry_val = carry_val && result ; 

} 

if (carry_val) return (allowed->enabelor) ; 

if( allowed->next_enabelor « NULL) return (FALSE); 

} 

/* 

* this next little loop covers the condition that there are no 
enabelors 

*/ 

for (next = trans->pre_places ; next != NULL; 
next = next->next_place) 

{ 

if (next->place->place == NULL) 

{return (FALSE) ;} 
else 

{result =TRUE; 

possible_value = next->place->place->object ; 



a 
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> 

> 

if (result) return(possible_value) ; 
else return (FALSE) ; 

> 

else 

{ 

return (FALSE) ; 

> 

> 


/* ********************************************************** 

* A routine which, "fires" a transition. Firing a transition 

* consists ofc Flashing the transition. 

* removing one token (which must match the passed 

* parameter "token") from each input place. 

* adding one token to each output place. 

* running the routine associated with the transition. 

* 

* Note that this routine should only be called if 

* transition_enabled_p(trans) returned a value of TRUE. 

* 

* Arguments * trans: a pointer to a transition. 

* token: the value of the legitimate token 

* to be removed. 

* Returns: the integer value of the routine associated with 

* the transition 

* Requirements: 

* I*:********************************************************/ 

int fire_transition(trans .token) 

int token; 

struct transition *trans; 

{ 

struct pre_pointer *next ; 
struct post.pointer *nnext ; 
int return_cond; 

if (graphics) f lash_pltr(trans - world); 

next = trans->pre_places ; 
while (next ! = NULL) 




if (remove_token( (next->place ~ kplace.ptr.arrayCO] ) 
,token,trans , 

next->decoloration_routine)*» ERROR) 

{ 

perror ( "f ire.transit ion : remove.token : " ) ; 
exit (0) ; 

> 

else { 

next= next ->next .place; 

> 

> 

nnext - trans->post .places ; 
while (nnext ! » NULL) 

< 

if ( ! (nnext->remote ) ) { 

add_token( (nnext->place - 4place_ptr_ array CO] ) , 
(*nnext->coloration_routine) (token)) ; 

> 

else if ((*nnext->data_trans_routine) (nnext ->r emote, 
(nnext->place - 4place_ptr_ array [0] ) 

, (*nnext->coloration_routine) (token)) 

!- 1 ) 

{ 

perror ("fire.transit ion : add.token(remote) :”) ; 
exit (0) ; 

> 

nnext = nnext->next .place ; 

> 

return.cond * (trans->routine) () ; 
if ( (trans->menu_requirements != NULL) 44 
trans->consumes_menu) 
if (increment _menu_ptr() == ERROR) { 

printf ("attempting to increment menu pointer with 
\n") ; 

printf ("head == tail in */.s Exiting.. \n", title); 
exit (l) ; 

> 

return (return.cond) ; 

> 
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/* ******************************************************** 

* A whole bunch of dummy routines which may be attached 

* to the transitions. 

* 

* Arguments: none 

* Returns: Note: for these to match the rest of the code, 

* all routines must return type int. 

* Requirements: see returns 

* 

int dummyQ-C retura(l);} 


A. 7 petri. c 

This cryptically named file has the routines for calculating the offsets from the 
other axes when computing the routing of the arcs. 


/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute. 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
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** Exploration, Troy, Now York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: petri. c 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains routines to calculate the offsets 
** an arc should have from the other arcs. 

** 

** Modification History: 

** 

*/ 

♦include <stdio .h> 

♦include "pltr . h" 

♦include "draw.h 11 

♦define True 1 

♦define False 0 
♦define None (-1) 


/* pltrtype pltr [MaxPITr] ; 

arctype arc[MaxArc] ; 

int npltr, narc; */ 

/* 

* This routine calculates the y offset within a row 

* for an arc. (eg, it might be in the 4th row, which 

* is a cm wide, and 6 nun from the top of it. 

* 

* Arguments: coll, col2, row, integers stateing the beginning 

* and ending points of a segemnt of an arc. 

* Returns: integer: the offset value 
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* Requirements: 

* m/ 

zoff(coll, col2 , row) 

int coll, col2, row; 
int i , off ; 

for(i*off=0; i < naxc; off++) 
for (i=0; i<narc; i++) { 

if (axe [i] .used kk arc[i] .yl == row kk 
overlap (col 1 , col2, 
arc[i].xO, arc[i] .x2) kk 
arc[i] .offl « off) 
break; 

if (arc[i] .used kk arc[i] .y3 == row kk 
overlap(coll , col2, 
arc[i].x2, arc[i] .x4) kk 
arc[i] .off 3 off) 

break; 

> 

return off-1; 

> 

/* 

* This routine calculates the x offset within a column 

* for an arc. (eg, it might be in the 4th column, which 

* is a cm wide, and 6 mm from the left of it. 

* 

* Arguments: rowl, row2, col, integers 3tateing the beginning 

* and ending points of a segemnt of an arc. 

* Returns: integer: the offset value 

* Requirements: 


yoff(rowl, row2, col) 
int rowl, row2 , col; 

{ 

int i , off ; 

f or(i=off =0 ; i < narc; off++) 
for(i»0; i<narc; i++) { 

if (arc[i] .used kk arc[i] .x0 *= col kk 
overlap(rowl , rowl, 
arc [i] . yO , arc[i] .yl) kk 
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arcCi] . offO » off) 
break; 

if (arc [i] .used 44 arcCi] .x2 ** col 44 
overlap (rowl , row2, 
arcCi] .yl, arc[i] .y3) 44 
arc[i] .off 2 ** off) 
break; 

if (arc [i] . used 44 arcCi] -x4 »= col 44 
overlap (rowl , row2, 
arc[i] .y3, arcCi] .y5) 44 
arcCi] .off 4 == off) 
break; 

> 

return off-1; 

> 


/* 

* A trivial boolean 



★ 

* Arguments: all integers. 

* Returns :true/false depending 

* Requirements: 

if a is between x and y 

or not 

* — — — — — — —————————— 

between (x, y, a) 

i 

return ((y >= a 44 a >= x) 

> 

|| (y <=* a 44 a <= x) ) ; 


* 

* Argument s : 

* Returns : 

* Requirements: 

* 

* — 

overlap(a, b, x, y) 
int a, b, x, y; 

< 

return ( between (x, y, a) 1 

1 between (x, y, b) II 



(a==x 44 b==y) I I (a==y 44 b==x) ) ; 

> 
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A. 8 postn.c 

This file contains the routine that actually calculates the routes for the arcs. 

/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute. 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 

** 

** File:postn.c 
** 

** Written By: Michael Mittmann 
** 

♦* Date: 1/30/91 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains the routine that positions the arcs 
** based on their start and end points. 
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** 

** Modification History: 
** 

*/ 

♦include <stdio.i> 
♦include "pltr.i" 




* 

* Arguments: i tie number of tie arc to be positioned. 

* Returns : notiing 

* Requirements: 


void arc_postn(i) 
int i ; 

int xfrom, yfrom, xto, yto , from, to; 


from 3 arc[i] .src; 
to » arc[i].dest; 

xfrom » pltr[from] .x; 
yfrom = pltr[from] .y; 

xto = pltrCto] .x; 
yto = pltrCto] .y; 

arc[i] .yO = yfrom; 
arc[i] .xO ■ xfrom; 

arc[i] .offO = yoff Carc[i] .yO, arc[i].yl, arc[i] .xO) ; 

arc[i].yl = yfrom + 1; 

if (xto < xfrom) 
arc[i] .x2 - xto + 1; 

else if (xto > xfrom) 
arc[i] .x2 * xto - 1; 

else if ((yfrom+2) =* yto) 
arc[i] .x2 = xto ; 
else 
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arc[i] .x2 * xto 

- l; 



arc[i] .offl 

* xoff (arc[i] .x0 , 

arc[i] .x2. 

arcCi] .yl) ; 

arc[i] .y3 = 
arc[i] .off 2 

yto - 1; 

* yoff (arcCi] .yl , 

arc[i] .y3 , 

arc[i] . x2) ; 

arc[i] .x4 3 
arc[i] .off 3 

xto ; 

= xoff (arc [i] .x2. 

arc[i] .x4. 

arc[i] . y3) ; 

arc[i] .y5 * 
arc[i] .off 4 

yto; 

* yoff (arc [i] .y3, 

arc[i] .y5 , 

arc[i] .x4) ; 


> 


A. 9 read_socket.c 

This file contains the routine which reads the socket upon getting an interupt. 

/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute. 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 


** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: read.socket .c 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains a routine to read all of the sockets 

** available to a particular program, and deal with any 

** incomming data according to the established protocol. 

** 

** Modification History: 

** 

*/ 

♦include <stdio.h> 

♦include <signal.h> 

♦include "pet . h " 

♦include "dumb_dec.h" 

extern int should_pause, graphics ; 

extern int socket _arr[] ; 
int io_came; 
extern char titled ; 


/* 

* This routine sets a boolean which is used by main() 

* whenever anything comes in over the socket . 

* 

* Arguments: none 

* Returns : nothing 

* Requirements: the interupt must be enabeled (this is 

* done in the sock_start() routines. 


void io_interupt_handler() { 



io.came ■ TRUE; 
should.pause * FALSE; 

> 

/* 

* This routine reads the all of the sockets until they are 

* empty. 

* The routine looks long, but it just does the same thing 

* over and over. Basically: 

* i *0; 

* while(i < number of sockets) 

* { 

* data = read(socket [i] ) 

* if (data == PLAC) 

* then the message says to add a token to a 

* place , deal with it . 

* else if (data =»* ADD_TAPE_END) 

* then the message says to add somthing to 

* the end of the tape , deal with it . 

* else if (data -= ADD .TAPE. IMMED I ATE) 

* then the message says to add somthing to 

* the current position of the tape, deal with it. 

* else increment to the next socket. 

* > 

* 

* Arguments: number_of .sockets . tells the routine how many to 
check. 

* Returns : Nothing 

* Requirements: An open socket for each number.of .sockets 

* 

void io .handler (number. of .sockets) { 
int i=0 , j , array_num,type, command.number; 
char data.byte; 

io.came = FALSE; 

while (i < number.of .sockets) { 

if (read(socket_arr[i] , ^command.number, sizeof(int)) < 0){ 
perror ("reading stream message (first)"); 
exit (1) ; 

> 

else if (command.number ■■ (int) PLAC) 

{ 
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if (read(socket_arr[i] , karray.num, sizeof(int)) < 0){ 
perror(" reading stream message (second) ") ; 
exit (1) ; 

if (read( socket _arr [i] , *type, sizeof (int)) < 0){ 
perr or ("reading stream message (third) ") ; 
exit (1) ; 

> 

add_token(array_num, type); 
should.pause 3 FALSE; 
i 3 0; 

else if (command.number 33 (int) AD_TAPE_END ) 

{/* add stuff dealing with adding tape data...*/ 

/* note that commands to add stuff to the tape are 

of the form: 

AD.TAPE.END number_of .additions additionO 
additionl .... 

*/ 

if (read(socket_arr[i] , Jtarray.num, sizeof (int)) < 0){ 
perr or ("reading stream message (fourth) ") ; 
exit (1) ; 

> 

if (array _n. uni > SIZE.MENU) 

printf ("Attempting to add to many tape 

commands \n") ; 

for(j=0; j<array_num; j++H 

if (read(socket_arr[i] , itype, sizeof(int)) < 

OK 

perror ("reading stream 
message (fifth) ") ; 
exit (1) ; 

} 

if (add_menu_cmnd( (enum tape.cmnd) type) == 

ERROR) 

printf ("tape add failed \n") ; 
if (graphics) draw.tape.box (current .tail.of _tape() -1); 

> 

i ■ 0 ; 

if (command.number 33 (int) AD .TAP E. XMMED X ATc. ) 

{ /* add stuff dealing with adding tape 

dat a ... * / 
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/* note that commands to add stuff to the tape 
are 

of the form: 

AD_TAPE_ IMMEDIATE number _of .additions 
addition5 addition4 addition3. . . . 

Nota that they are in reverse order because the 
insertion process switches the order. 

*/ 

if (read(socket_arr[i] , larray.num, sizeof(int)) < Q){ 
perrorC" reading stream message (fourth) ") ; 
exit (1) ; 

> 

if (array _num > SIZE.MENU) 

printf ("Attempting to add to many tape 

commands \n") ; 

for(j=0; j<array_num; j++K 

if (read(socket_arr[i] , itype, sizeof(int)) < 

OK 

perror("reading stream 
message(f ifth ) ") ; 
exit (1) ; 

> 

if (insert _menu_cmnd_immediate( (anum tape_cmnd) 
type) 

=>=■ ERROR) 

printf ("tape add failed \n") ; 
if (graphics) 

draw_tape_box(current_head_of_tape()) ; 

> 

i = 0; 

> 

else if (command_number ==* (int) DATA) 

< 

if (read(socket_arr[i] , &array_num, sizeof(int)) < 0){ 
perror("reading stream message (eigth)"); 
exit (1) ; 

> 

for(j=0; j<array_num; j++){ 

if (read(socket_arr[i] , ftdata.byte, sizeof (char) ) <0){ 
perror(" reading stream (ninth)"); 
exit (1) ; 

> 
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/* this is where a routine doing something with */ 
/* the data would be. */ 

> 

i » 0; 

> 

else i++; 

command.number = 0 ; 

> 

should.pause = FALSE; 

> 

A. 10 sock_connect.c 

This file handles connecting to already existing sockets. 


/* 

** 

** 

** 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 
1990 ALL RIGHTS RESERVED. 


** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 


** 


Package : TokenPasser 



** File: sock_connect . c 
** 

** Written By: Michael Mittaann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main . c . 

** This file contains a routine to connect to the specified 
** pre-existing socket (s) 

** 


** Modification History: 
** 


*/ 


•include 
•include 
• include 
•include 
•include 
•include 
•include 
•include 
•include 
•include 
•include 


< sys /types .h> 
<sys /socket .h> 
<netinet/ in.h> 
<netdb .h> 
<stdio .h> 

<f cntl .h> 
<sys/uio .h> 
<ermo .h> 
<signal .h> 

"pet .h" 
"dumb_dec .h" 


•define NUM_INFQ_PER_SOCK 2 

/* This program creates a client process 

on a socket by asking for a connection */ 

int socket _arr[LQCAL_SOCKS] ; 

extern struct place.ptr place_ptr_array □ ; 


/* 

* This routine connects to the sockets specified in the 

* co mm a n d line argument . The socklets are marked as 

* Asynchronous, non-blocking sockets. 

* 

* Arguments: argv, argc. argv is an array of character 

* strings. Since the command line for any module which 

* uses sock_connect is 
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* <cmnd><location><number> [<locationXnumber>] [-fast] 

* the locations said numbers are read from that array 

* and used by the routine. 

* Returns : Nothing 

* Requirements : This must be called after the sockets are 

* opened. (not much of a problem, as you don't have 

* eno ug h information to call this until the socket is 

* opened . 

* — : */ 

void sock. start (argc , argv) 

int argc; 
char *argv □ ; 

int sock_num(LOCAL_SOCKS] ,i; 

struct sockaddr.in server; 

struct hostent *hp, *gethostbyname() ; 

if ((argc < NUM.INFO.PER.SOCK+LOCAL.SOCKS +1)11 (argc > 
NUM.INFO.PER.SQCK* 

LQCAL.SQCXS +2) H 

fprintf (stderr , "The number of local sockets (in pet.h) does 
not\n") ; 

fprintf (stderr, "match the number given implicitly in the 
commandNn") ; 

fprintf (stderr, "Local socks = %d, you should give the host 
name \n") ; 

fprintf (stderr, "and socket number for each socket\n") ; 
exit (1) ; 

> 

/* this is the line which tells the interupts where to go... */ 
signal (SIGIQ, io.interupt .handler) ; 

for (i=0 ; i<LQCAL_SOCKS ; i++){ 
sock_num[i] = atoi(argv[2+NUM_INF0_PER_S0CK*i] ) ; 
if ( (socket _arr [i] 3 socket (AF.INET,S0CK_STREAM,0) ) <0)-( 
perr or ("client :open: ") ; exit (1) ; } 

server . sin.family * AF.INET ; 

hp = gethostbyname ( argv [NUM.INFO .PER.SOCK * i+l]) I 
if (hp == 0) { 

fprintf (stderr , "*/.s: unknown host", 
argv [NUM.INFO.PER.SQCK * i+l]); 
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exit (2) ; 

> 

bcopy((char *)hp->h_addr , (char 
*)4server .sin_addr,hp->h_length) ; 
server. sin.port ■ htons(sock_num[i] ) ; 

if (connect (socket _arr[i] , (struct sockaddr *)4server, 
sizeof server) <0)-( 
perror ("client : connect : ; 
exit (1) ; 

> 

printf ("opened socket to %s Xd = %d \n ", 
argv[NUM_INFO_PER_SOCK * i+l] , sock_num[i] .socket _arr[i] ) ; 
if (fcntl ( socket _arr [i] ,F_SET0WN, getpid())<0H 
perror("fcntl F.SETOWN, 
exit (1) ; 

> 

if (fcntl (socket. arr [i] ,F_SETFL, FASYNC|FNBI0)<0H 
perror("f cntl F.SETFL, FNBIO IFASYNC") ; 
exit (l) ; 

> 

> 

> 

A. 11 sock_open.c 

This routine opens up sockets for sock_connect to connect to. 


/* 

** 

** 

** 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 
1990 ALL RIGHTS RESERVED. 


** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 


** special, incidental or consequential damages arising out 
** of tlie use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
★* has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: sock_open.c 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 

** main.c. 

** This file contains a routine to open to the specified 

** socket (s) 

** 

** Modification History: 

** 

*/ 

#include <sys/types .h> 

#include <sys/socket ,h> 

#include <netinet/in.h> 

#include <netdb .h> 

^include <stdio . h> 

#include <fcntl.h> 
tinclude <ermo.h> 

#include <signal . h> 

#include "pet .h" 

#include "dumb^dec .h" 

/* This program sets up a server (connection 

receiver) to listen for a message on a socket. 

When it receives a message, it displays the 
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message on stdout, sends the same message back 
to the sender, and exits */ 

/* This program is called by main2 

* It sets up some sockets and writes their addresses out to the 
screen 

*/ 

extern int place □ ; 
int 3ocket_arr [MAIN.SOCKS] ; 

/* 

* This routine opens MAIN_S0CKS sockets. 

* The socklets are marked as Asynchronous, non-blocking 

* sockets . 

* 

* Arguments: none, (argv and argc are ignored, they are 

* there so this routine looks like sock_connect . 

* Returns : Nothing 

* Requirements: none 

* */ 

void sock_staxt (argc , argv) 

int argc; /* these are to make this program */ 

char *argv[] ; /* compatable with sock.start in 

sock.connect . c */ 

{ 

int ns [MAIN_S0CKS] , 1 , sock_nums [MAIN_S0CKS] , stringlen; 
int j , connections_need_to_be_made, 
need_to_connect_to [MAIN_S0CXS] ; 
struct sockaddr_in sock_name [MAIN_SQCKS] ; 

/* specify the name of the routine that handles SIGIO interupts */ 
signal (SIGIO, io_interupt_handler) ; 

/* Set the permission so that the SIGIO/SIGURG interupts can be 
sent 

♦ set up listening sockets, and allow receipt of asynchronous I/O 

* signals 
*/ 

for ( i=0 ; i<MAIN_S0CKS ; i++) { 
if ( (ns [i] » socket (AF.INET , SOCK .STREAM , 0))<0){ 
perror(" server : socket : opening error: ") ; 
exit(l) ; 
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> 

if CfcntlCnsCi] ,F_SETFL, FHBIOXOX 
perror("f cntl F_SETFL, FNBIO"); 
exit(l) ; 

> 

> 

/* Name tlie socket using wildcards */ 
for (i=0;i<MAIN_S0CKS;i++H 
3 ock_name [i] . sin.f amily ■ AF.INET; 
sock_name[i] .sin.addr. s_addr = INADDR_ANY ; 
sock_name[i] .sin_port =* 0; 

if (bind (ns [i] , (struct sockaddr *)*sock_name[i] .sizeof 
sock_name[i] 
perror("server:bind") ; 
exit (1) ; 

> 

stringlen = sizeof sock_name[i] ; 

if (get sockname (ns [i] , (struct sockaddr *)4sock_name[i] , 
Jtstringlen) <0) { 

perror(" getting socket name:"); 
exit (1) ; 

> 

sock_nums [i] = ntohs(sock_name [i] . sin_port) ; 
printf ("socket port #%d has opened \n" , 
ntohs(sock_name[i] .sin_port)); 

> 

for (i=0 ; i<MAIN_S0CKS ; i ++ ) 
listen (ns [i] ,3) ; 

/* accept connection request */ 

/* these should be marked as non-blocking, and go through, and 
attempt to 

* accept until all of the connections are accepted. Note that 
the hassle 

* of dealing with non-blocking sockets is so that we don't have 
to connect 

* in order. 

*/ 


for (i=*0 ; i<MAIN_SQCKS ; i++) 
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need_to_connect_to [i] ■ TRUE; 
connections_need_to_be_made * TRUE; 
while (connect ions_need_to_b«_nade)-( 
for (i*0;i<MAIN_S0CXS;i++H 
if (need_to_connect_to [i] ) { 

3ocket_arr [i] * accept (ns [i] , (struct sockaddr *)0, (int 
*) 0 ) ; 

if ( (socket _arr[i] < 0)4k (errno !* EWOULDBLQCK) ) 
perror(" server: accept") ; 

else if (ermo !- EWOULD BLOCK ){ 
printf ("connection opened\n") ; 
need_to_connect_to [i] * FALSE; 
if (fcntl(socket_arr [i] ,F_SET0WN, getpid())<0)-( 
perror("fcntl F.SETOWN, :"); 
exit (1) ; 

> 

if (fcntl(socket_arr[i] ,F_SETFL, FASYNC|FNBI0)<0){ 
perror ("f cntl F.SETFL, FASYNC"); 
exit (1) ; 

> 

connect ions_need_to_be_made =* FALSE; 
for(j*0;j<MAIN_S0CKS;j++) 

connections _need_to_be_made I* 
need_to_connect_to [j] ; 

> 

> 

> 

> 

> 

A. 12 transform. c 

This routine translates from the default data structure to one which the draw- 
ing routines use. 


/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute. 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
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** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequent ial damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party . 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: transform. c 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains routines to transform the the data 
** to the pltr data structures. This is needed because 

** drawing routines use the pltr data structures , and 

** the firing routines use the other data structures. 

** This should probably be modified, but "if it ain J t 

** broke don't fix it". 

** 

** Modification History: 

** 

*/ 

#include "pltr.h 11 
tinclude "pet . h" 

#include "dumb.dec .h" 
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♦define MAX.PLACES 70 /* note, this number is likely to be */ 

/* one of the things giving you */ 

/* trouble when you remake the nets */ 

extern struct place.ptr place_ptr_ array □ ; 
extern int num .transit ions; 

/* 

* f ill_pltr_ arc _map (world) 

* This routine takes the set of data structures defined in 

* world and fills the pltr data structures, so that the 

* graphics package can be used. 

* 

* quick pseudocode: 

* for each transition: 

* put that transition on the pltr list. 

* for each preplace of that transition 

* if that place has not yet been put into the pltr list 

* put it in the list 

* mark the connections betveeen the place and transition. 

* put the arc between them on the arc list 

* otherwise 

* mark the connections between the place and the 
transition. 

* put the arc between them on the arc list 

* for each postplace of that transition 

* if that place has not yet been put into the pltr list 

* put it in the list 

* mark the connections betweeen the place and transition. 

* put the arc between them on the arc list 

* otherwise 

* mark the connections between the place and the 
transition. 

* put the arc between them on the arc list 

* 

*Note, the pltr list is a list of all the places and 
transitions . 

* 

* Arguments: world: an array of all the transitions. 

* Returns : nothing 

* Requirements: Note that this is called only after the other 


* data structure is completed. 

* */ 
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void fill_pltr.arc.map (world) 
struct transition world [] ; 

< 

int arc_counter, i .place.num; 
struct pre.pointer *next ; 
struct post.pointer *nnext; 

arc.counter = 0; 

for (i=0;i<num_transitions;i++) /* for each transition 

*/ 

{ 

if ( (world [i] .pre_places \- NULL) I I 
(world [i] .post .places !■ NULL)) 
mark_tran(i .world [i] .x.loc, worldCi] .y.loc) ; 
next 3 world [i] . pre.places ; 
while (next ! » NULL) { 

if ( (place.num = already_listed_p(next->place)) <0) 

place.num = -l*place_num + num.transitions ; 
f ix_arc_po inter (i ,place_num, arc.counter .TRUE) ; 

> 

else 

place.num 3 place.num + num.transitions ; 
mark.place (place.num, arc.counter, TRUE, 

next->place->x_loc, next->place->y_loc) ; 
mark_arc(i ,place_num, arc.counter, TRUE) ; 

> 

arc_counter++ ; 

next 3 next->next_place; 

> 

nnext = worldCi] .post .places ; 
while (nnext != NULL){ 

if ( (place.num 3 already_listed_p(nnext->place) ) <0) 

place.num 3 -l*place_num + num.transitions; 
fix_arc_pointer(i .place.num, arc.counter, FALSE) ; 

> 

else 

{ 

place.num 3 place.num + num.transitions; 
mark.place (place.num, arc. count er , FALSE, 

nnext->place->x_loc , nnext->place->y_loc) ; 



mark_arc(i,place_num, arc_counter, FALSE) ; 

> 

arc_counter++ ; 

nnext » nnext ->next .place; 

> 

} 

> 


/* 

* checks to see if the place has already been added to the 

* database, if it has then this returns -1* it's location. 

* Otherwise it returns its new location. 

* 

* Arguments: canidate_place . A pointer to the place being 
checked. 

* Returns : A number (place in in the pltr array) for that 

* place. (if the number is negitive the place has 

* already been located. 

* Requirements: 

* -* 

int already_listed_p(canidate_place) 

struct place.ptr *canidate_place; 

{ 

static int place.markers [MAX.PLACES] * -CO}; 
int i ; 

i = canidate_place - Jt(place_ptr_array[0] ) ; 
if (place_markers [i] ) return (-1 * i) ; 
else place .markers [i] = TRUE; 
return (i) ; 

> 


/* 

* this deals with changing all of the data if a new arc 

* is to be added to a place which was already declared. 

* Specif ically , a place in the arc array must be set 

* aside, and the linkled lists of arcs in the pltr lists 

* must have the new arc added. 

* 

* Arguments: tran.num, place.num, arc.num: the number in 

* their respective arrays of the transition, place. 


* and arc . 

* pre: a boolean, true if the place is a 

* pre-place to the transition. 

* Returns : nothing 

* Requirements: 

* 

void fix_arc_po inter (tran.num, place_num, arc_num, pre) 
int tran_num, place.num, arc_num, pre; 

/* note pre is a boolean indicating*/ 

/* if the place is a pre-place or a*/ 

/* post-place */ 

int base_arc; 

arc [arc_num] . srcnext = NullArc ; 
arc [arc_num] .destnext = NullArc; 

if (pre)-C 

if (pltr [place_num] . out » NullArc){ 
pltr [place_num] . out = arc.num; 
arc [arc_num] . src = place_num; 
arc [arc _nmn] .dest = tran_num; 

> 

else-C 

base_arc = pltr [place.num] . out ; 

while (arc [base_arc] .srcnext != NullArc) 

{ base_arc = arc [base_arc] .srcnext ;} 
arc [base_axc] . srcnext = arc.num; 
arc [arc_num] . src = place_num; 
arc[arc_num] .dest = tran._n.mn; 

> 

f ix_tran_ input _arcs (tran_num , arc.num) ; 

"> 

else{ 

if (pltr[place_num] . in == NullArc) { 
pltr [place_num] . in = arc_num; 
arc [arc_num] . dest = place.num; 
arc [arc_num] . src = tran.num; 

> 

else{ 

base.arc = pltr[place_num] . in; 

while (arc [base_arc] . destnext ! = NullArc) 

{ base_arc = arc[base_arc] .destnext;} 
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arc[base_arc] .destnext * arc.num; 
arc [arc.num] .dest » place.num; 
arc [arc_num] . src » tran_num; 

> 

f ix_tran_output_arcs(tran_num, arc.num) ; 

> 

arc [arc.num] .used * TRUE; 

arc [arc_num] .srcnext * NullAxc; 

arc [arc_num] .destnext =■ NullArc; 

} 

/* 

* this routine fixes the pointers associated with the 

* transitions which have arcs leading into them. 

* (that is, this routine is called when we're adding the 

* arc arc.num to tran.num's list of arcs which input to 

* it . 

* 

* Arguments: tran_num, arc_num, the array number of the 

* transition and arc. 

* Returns : nothing 

* Requirements: 

* */ 

void f ix_tran_input_arcs(tran_num, arc.mun) 

int tran_num, arc_num; 

{ 

int base_arc; 

if (pltr[tran_num] . in == NullArc) { 
pltr [tran.num] . in = arc_aum; } 
else-( 

base_arc = pltr [tran.num] . in; 
while (arc [base.arc] .destnext NullArc) 
base_arc » arc [base.arc] . destnext ; 
arc [base_arc] .destnext 3 arc_num; 

> 


/* 

* this routine fixes the pointers associated with the 

* transitions which have arcs leading out of them. 

* (that is, this routine is called when we're adding the 

* arc arc_num to tran_num's list of arcs which output 
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* from it. 

* 

* Arguments : traLn._n.um , aLrc_uum, the array number of the 

* transition and arc. 

* Returns : nothing 

* Requirements: 

* 

void f ix_tran_output_arcs(tran_num, arc_num) 

int tran_num , arc_num ; 

{ 

int base_arc; 

if Cpltr[tran_num] .out == NullArc) { 
pltr [tran.num] .out * arc_num; } 
else{ 

base.arc = pltr [tran_num] .out ; 

while (arc[base_arc] .srcnext != NullArc) 

{ base_arc = arc [base_arc] . srcnext ;} 
arc [base_arc] . srcnext = arc_num; 

> 

> 


-*/ 


/* 


* this routine records a place in the data structure the 

* first time it is encountered. 

* 

* Arguments: (sigh, isn’t this obvious by now?) 

* place.nura, arc_num: the array number of the relevent things 

* x_loc, y_loc, the desired screen locations. 

* pre_place : boolean, true if pre-place relit ive to 

* the current transition when this place was "discovered" 

* Returns: Nothing, nada, zip. 

* Requirements: 

* 

void mark_place(place_num, arc_num, pre_place,x_loc, y_loc) 

int place.num, arc_num, pre.place ; /* note pre is a boolean */ 

int x_loc, y_loc ; Vindicating if the place is a pre-*/ 

/♦place or a post-place */ 


{ 


if (pre_place) {pltr [place_num] .out = arc_num; 
pltr [place _num] . in = NullArc;} 
else {pltr [place.num] .in = arc.num; 

pltr [place_num] .out = NullArc;} 
pltr [place_num] .place * TRUE; 
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pltr [place_num] .used * TRUE; 
pltr [place_num] .type * PIState; 
pltr [place_num] .tok * 0; 
pltr[place_num] .x * x_loc; 
pltr [place_num] .y = y_loc; 

> 

/* 

* This fills the data structure for an arc associated with 

* a place the first time that that place is encountered... 

* 

* Arguments: tran_num, are_num , place_num: 

* the array locations of the relevent objects. 

* pre: boolean, true if place is input to transition 

* Returns : nothing . 

* Requirements: 

* */ 

void mark_arc(tran_num, place.num, arc_num, pre) 

int tran_num, place_num, arc_num, pre; 

/* note pre is a boolean indicating*/ 

/* if the place is a pre-place or a*/ 

/* post-place */ 

{ 

arc [arc.num] .used = TRUE; 
arc [arc_num] .srcnext * NullArc; 
arc [arc.num] .destnext = NullArc; 
if (preH 

arc [arc_num] . src = place_num; 
axe [arc_num] . dest = tran_num; 
f ix_tran_ input _axcs (tran.num , axe num) ; 

> 

else-C 

axc[arc_num] .dest = place.num; 
arc [arc _ num] . src = tran_num; 
f i*_tran_output_arcs(tran_num, arc num); 

> 

> 

/* 

* this routine initializes a transition 

♦ 

* Arguments: tran_num: the number of the transition? 

* x_loc, y_loc: location of the transition 



* Returns : nothing 

* Requirements: 

* 

void mark_tran(tran_num,x_loc, y.loc) 

int tran_num,x_loc, y_loc; 

< 

pltr [tran.num] .place * FALSE; 

pltr[tran_num] .used ■ TRUE; 

pltr [tran_num] .type * PlEvent ; 

pltr [tran.num] .tok * 0; /* fix this! ! ! ! ! ! */ 

pltr [t ran _num] .x * x_loc; 

pltr[tran_num] .y = y_loc; 

pltr [tran_num] . in 3 NullArc; 

pltr [t ran _num] .out =* NullArc; 

> 

/* 

* removes a token from the pltr representation of place 

* place_num. 

* note the relitve lengths of documentation and code. 

* 

* Arguments: place number 

* Returns : nothing. 

* Requirements: 

* 

void remove_tok_in_pltr_rep(place_num) 

int place_num; 

{ 

pltr [place_num + num_transitions] .tok — ; 

> 




* adds a token to the pltr representation of place 

* place_num. 

* note the relitve lengths of documentation and code. 

* 

* Arguments: place number 

* Returns : nothing . 

* Requirements: 

* 

void add_tok_in_pltr_rep(place_num) 

int place_num; 



{ 

pltr [place_num + nuo_transitions] .tok++; 

> 


A. 13 window_manager.c 

This routine opens and moniters the window. 


/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute. 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 

** File: window_manager 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 


** Purpose : The purpose of the package can be found in the file 
** main . c . 

** This file contains a routine which monitors the window, 

** and updates it when needed. It also sends signals to 
** it J s child (the main routine) when the user gives 

** instructions it's to senile to handle. 

** This file also contains the routine which initially 
** creates the window. 

** As a final ingredient the file contains spam sauteed 

** in the finest grease-ridden-carp grease, and due to 

** a special deal with Dahli-lama Export/Import, 2 
** drams of yak hair. 

** 

** Modification History: 

** 

*/ 

♦include "dumb_dec.h" 

♦include <signal.h> 

♦include <X11/Xlib.h> 

♦include <X11/Xutil .h> 

♦define TRUE 1 
♦define FALSE 0 

extern char titled ; 
char f ontname [] ={"6x10"} ; 

Display ^display; 

Window aet_window; 

GC gc; 

unsigned long foreground, background; 

XEvent event ; 

Font font; 

KeySym key; 

XSizeHints hint; 
int screen; 
char text [ 10 ] ; 


/* 

* This routine creates the window. 



* Arguments: none 

* Returns : none 

* Requirements: Xll library? 

* — * 

void init_window(){ 

display 3 XOpenDisplayC'"’) ; 
screen 3 DefaultScreen(display) ; 
background 3 WhitePixel (display, screen); 
foreground 3 BlackPixel (display , screen) ; 
font 3 XLoadFont (display .fontname) ; 

bint .x =0 ; hint . y» 0 ; 

hint . width=350 ; hint. height 3 250; 

hint. flags 3 PPosition iPSize; 

/* create window*/ 

net .window 3 XCreateSimpleWindow (display, 

Def aultRootWindow(display) , 
hint.x, hint.y, hint. width, hint. height, 5, 
foreground, background) ; 

XSetStandardProperties (display, net.windov, title, title. 
None , 

0,0, 4hint ) ; 

/* GC initialization & creation */ 

gc 3 XCreat eGC (display , net.window, 0,0); 

XSetFont (display, gc, font) ; 

XSetBackground (display , gc, background); 

XSetForeground (display , gc, foreground); 

/* input event selection */ 

XSelectlnput (display, net .window, KeyPressMaskl 
ExposureMask) ; 

> 


/* 

* this routine is a nice little infinite loop which 

* waits for the user to move the window, or type something 

* into it , or someone to put another window over it , 



* or anything like that. 

* 

* The routine sends messages to it's child by using the 

* kill command (and the child never sends messages back, 

* isn't that just typical?) which is why the child’s pid is 

* passed to the routine. 

* 

* Arguments: pid. the pid of the process which needs to be 

* notified to refresh the screen, or has to be killed 

* when the user tells the program to end. 

* Returns : Never . 

* Requirements : XI 1 stuff, and the child needs to know what to 

* do with a SIGUSR1 signal. 

* */ 

event _reading_loop (pid) 

int pid; 

{ 

int not_done = TRUE.i; 

while (not .done) 

{ 

XWindowEvent (display, net.window, 
(long)KeyPressMasklExposureMask, ftevent ); 

switch(event .type) 

case Expose: 

while (XCheckWindowEvent (display, net .window, 

(long) ExposureMask, Jtevent )) 

{/* empty all the expose events from the buffer..*/} 

/* tell child to redraw screen */ 
kill (pid, SIGUSR1) ; 
break; 

case MappingNotify : 

XRef reshKeyboardMapping (Jtevent) ; 
break; 

/* process keyboard input */ 
case KeyPress: 

i = XLookupString(4event , text, 10, ftkey, 0); 

/* quit */ 

if (i==l && text[0]== 'q') not .done * FALSE; 
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/* tell child to redraw screen */ 

if (i=*»l && text CO] ■■ 'r') kill(pid,SIGUSRl) ; 

break; 

default : 

printf("we fell through the case statement %s\n" .title) ; 
break; 

> 

> 

> 
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APPENDIX B 
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/* 

** 

** 

** 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged* 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: setup.disp.c 
** 

** Written By: Michael Mittmann 


setup.disp.c 

This is the file describing the Dispatcher. 


NOTICE OF COPYRIGHT 

Copyright (C) Rensselaer Polytechnic Institute. 
1990 ALL RIGHTS RESERVED. 
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** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains the net definition, statements defining 

** the dispatcher. 

** 

** Modification History: 

** 

*/ 

•include <varargs.h> 

#include "pet.h" 

•include "pet2.h" 

•include "dumb_dec.h" 

•define NUM.TRANS 33 

char titled = {"Dispatcher"}; 

int number.of .sockets = MAIN.SOCKS; 

int c al ib r ate .menu () , look.menuO , grasp.menuO , release.menuO , 
find .menu O ; 

int continue.visionQ , vision.taskO , motion.taskO , calr.menuC) , 

move.menuO ; 

int app roach. menu () ; 

extern int rec.timelO, rec_time2(); 
extern int socket.arr [] ; 
int menu[SI2E_MENU ] ; 
int num.transitions = NUM.TRANS; 
struct place.ptr place.ptr.array [70] ; 
struct transition world [NUM.TRANS] ; 

/* 

* maLke.net O 

* this routine just defines a net identical to the one described 

* in the GreatSPN1.5 file dispat cher.w.all.connect . 

* 

* Arguments : none 

* Returns : nothing 

* Requirements: just about all of the routines linked to it ;-) 

* */ 





139 


make.net () 

{ 

initialize_transition(calibrate_menu,TRAN world[Q] ,4,12) ; 
add.pre.list (4 (world [0] .pre.places) , 4place_ptr_ array [30] , 
4place_ptr_ array [42] , 

NULL) ; 

add.post.list (4(world[0] .post.places) , 4place_ptr_ array [32] ,0, 
4place_ptr_array [16] , socket _arr[0] ,NULL) ; 

initialize_transition(calibrate_menu,TRAN world[l] ,6,12); 
add.pre.list (4 (world [l] .pre.places) , 4place_ptr_array [30] , 
4place_ptr_array [45] , 

4place_ptr_array [39] .NULL) ; 

add.post.list (4(world[l] .post.places) , 4place_ptr_ array [34] ,0, 
4place_ptr_array [16] , socket _arr[0] .NULL) ; 

initialize_transition(vision_task,TRAN world[2] ,8,12) ; 
add.pre.list (4 (world [2] .pre.places) , 4place_ptr_array [30] , 
4place_ptr_array [44] , 

4place_ptr_array [38] .NULL) ; 

add.post.list (4(world[2] .post.places) , 4place_ptr_ array [35] ,0, 
4place_ptr_array [16] , socket _arr[0] .NULL) ; 

initialize_transition(vision_task,TRAN world[3] ,10,12) ; 
add.pre.list (4 f world [3] .pre.places) , 4place_ptr_array [30] , 
4place_ptr_array [33] , 

NULL) ; 

add.post.list (4(world[3] .post.places), 4place_ptr_array [36] ,0, 
4place_ptr_array [16] , socket.arr [0] .NULL) ; 

initialize_transition(vision_task,TRAN world[4] ,12,12) ; 
add.pre.list (4 (world [4] .pre.places) , 4place_ptr_array [30] , 
4place_ptr_array [38] , 

4place_ptr_ array [45] .NULL) ; 

add.post.list (4(world[4] .post.places) , 4place_ptr_array [37] ,0, 
4place_ptr_array [16] , socket _arr[0] .NULL) ; 

initialize_transition(rec_time2 .TRAN world[5] ,0,0) ; 

initialize_transition(rec_time2 .TRAN world[6] ,4,22) ; 
add.pre.list (4 (world [6] .pre.places) , 4place_ptr_ array [31] , 
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ftplace.ptr.array [32] , 

NULL); 

add.post.list (&(world[6] . post .places) , kplace.ptr. array [33] ,0, 
Jtplace.ptr.array [20] , socket _arr[0] .NULL) ; 

initialize_transition(rec_time2 .TRAN wo rid [7] ,6,22) ; 
add.pre.list (4 (world [7] .pre.places) , fcplace.ptr. array [31] , 
ftplace.ptr. array [34] , 

NULL) ; 

add.post.list (&(world[7] .post.places), Aplace.ptr.array [33] ,0, 
ftplace.ptr.array [20] , socket _arr[0] .NULL) ; 

initialize_transition(rec_tinie2 ,TRAN world[8] ,8,22) ; 
add.pre.list (4 (world [8] .pre.places) , 4place_ptr_ array [31] , 
4place_ptr_ array [35] , 

NULL) ; 

add.post.list (4(world[8] . post .places) , 4pl ace _ptr_ array [33] ,0, 
4place_ptr_array [20] , socket _arr[0] .NULL) ; 

initialize_transition(rec_time2 ,TRAN world[9] ,10,22) ; 
add.pre.list (4 (world [9] .pre.places) , 4place_ptr_ array [31] , 
ftplace.ptr.array [36] , 

NULL) ; 

add.post.list (4(world[9] .post.places) , kplace.ptr. array [33] ,0, 
4place_ptr_array [20] , socket _arr[0] .NULL) ; 

initialize_transition(rec_time2 ,TRAN world[l0] ,12,22) ; 
add.pre.list (4(world [10] .pre.places) ,4place_ptr_array [31] , 
4place_ptr_ array [37] , 

NULL) ; 

add.post.list (4(world[l0] .post.places) , 4place_ptr_array [33] ,0, 
4place_ptr_array [20] , socket _arr[0] .NULL) ; 

initialize_transition(motion_task ,TRAN world[ll] ,22 , 2) ; 
add.pre.list (4 (world [ll] .pre.places) ,4place_ptr_array [40] , 
4place_ptr_ array [46] , 

NULL) ; 

add_post_list(4(world[ll] .post.places) , 4place_ptr_array [41] ,0, 
iplace.ptr.array [5] ,socket_arr[l] .NULL) ; 

initialize_transition(rec_time2 ,TRAN world[l2] ,22,6) ; 
add.pre.list (4(world[l2] .pre.places) ,4place_ptr_array [41] , 
4place_ptr_array [48] , 
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NULL) ; 

add.post.list (*(world[12] .post .places) , ftplace.ptr. array [42] ,0, 
ftplace.ptr.array [9] , socket.arr Cl] .NULL) ; 

initialize_transition(motion_task .THAN world[13] ,22, 10) ; 
add.pre.list (ft (world [13] .pre.places) .ftplace.ptr.array [42] , 
ftplace.ptr.array [46] , 

NULL) ; 

add.post.list (ft(world[13] .post .places) , ftplace.ptr.array [43] ,0, 
ftplace.ptr.array [5] , socket _arr[l] .NULL) ; 

init ialize. transit ion(rec_t ime2 , TRAN world [14] ,22, 14) , 
add.pre.list (ft(world[l4] .pre.places) .ftplace.ptr.array [43] , 
ftplace.ptr.array [48] , 

NULL) ; 

add.post.list (ft (world [14] .post .places) , ftplace.ptr.array [39] ,0, 

"ftplace.ptr.array [44] ,0 .ftplace.ptr.array [9] , socket _arr[l] .NULL) ; 

initialize_transition(motion_task, TRAN world[15] ,28 , 16) ; 
add.pre.list (ft (world [15] .pre.places) , ftplace.pt r .array [59] , 
ftplace.ptr.array [46] , 

NULL) ; 

add.post.list Cft(world[l5] .post .places) , ftplace.ptr.array [50] ,0, 
ftplace.ptr.array [5] ,socket_arr[l] .NULL) ; 

initialize_transition(motion_task ,TRAN world[l6] ,28,18) , 
add.pre.list (ft (world [16] .pre.places) .ftplace.ptr.array [44] , 
ftplace.ptr.array [46] , 

NULL) ; 

add.post.list (ft(world[l6] .post .places) , ftplace.ptr.array [51] ,0, 
ftplace.ptr.array [5] , socket _arr[l] .NULL) ; 

init ialize.trans it ion(mot ion.t ask ,TRAN world[l7] ,28 ,20) , 
add.pre.list (&(world[l7] .pre.places) .ftplace.ptr.array [33] , 
ftplace.ptr.array [46] , 

NULL) ; 

add.post.list (ft(world[l7] .post .places) , ftplace.ptr.array [52] ,0, 
ftplace.ptr.array [5] , socket.arr [l] .NULL) ; 

initialize_transition(motion_task,TRAN world[l8] ,28,24) ; 
add.pre.list C&(world[l8] .pre.places) .ftplace.ptr.array [45] , 
ftplace.ptr.array [46] , 

NULL) ; 



add.post.list (A(world[18] .post .places) , Aplace.ptr.array [53] ,0, 
Aplace.ptr.array [5] , socket_arr[l] .NULL) ; 

initialize. transit ion (rec_time2, TRAN world[l9] ,32,20) ; 
add.pre.list (A(world[l9] .pre.places) ,4place_ptr_array[50] , 
4place_ptr_ array [48] , 

NULL) ; 

add.post.list (A (world [19] .post .places) , 4place_ptr_array [44] ,0, 
4place_ptr_ array [9] ,socket_aLrr[l] ,NULL) ; 

initialize. transit ion (rec_time2 ,TRAN world[20] ,32,22) ; 
add.pre.list (4(world [20] .pre.places) , 4place.pt r.array [51] , 
4place_ptr_array [48] , 

NULL) ; 

add.post.list (4(world[20] .post.places) , 4place_ptr_array [44] ,0, 
4place_ptr_array [9] , socket _arr[l] .NULL) ; 

initialize_transition(rec_time2,TRAN world[2l] ,32,24) ; 
add.pre.list (4 (world [21] .pre.places) ,4place_ptr_ array [52] , 
4place_ptr_ array [48] , 

NULL) ; 

add.post.list (4(world[2l] .post.places) , 4place_ptr_array [44] ,0, 
4place_ptr_array[38] ,0 , 4place.pt r.array [9] , socket _arr[l] .NULL) 

initialize_transition(rec_time2 ,TRAN world[22] ,32,28) ; 
add.pre.list (4 (world [22] .pre.places) ,4place_ptr_array [S3] , 
4place_ptr_array [48] , 

NULL) ; 

add_post_list(4(world[22] .post.places), 4place_ptr_array [45] ,0, 
Aplace.ptr.array [9] ,socket_arr[l] .NULL) ; 

initialize. transit ion (grasp.menu, TRAN world[23] ,14,28); 
add.pre.list (4(world[23] .pre.places) ,4place_ptr_array [44] , 
4place_ptr_array [54] , 

NULL) ; 

add.post.list (4 (world [23] .post.places) , 4place_ptr_array [56] ,0, 
4place_ptr_ array [0] , socket.arr [2] .NULL) ; 

initialize_transition(release_menu,TRAN world [24] , 18,28) ; 
add.pre.list (4 (world [24] .pre.places) , Aplace.ptr.array [45] , 
Aplace.ptr.array [54] , 

NULL) ; 

add.post.list (4(world[24] .post.places) , Aplace.ptr.array [57] ,0, 
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Jtplace.ptr.array [0] .socket.arr [2] .NULL) ; 

initialize_transition.(grasp .menu, TRAN world[25] ,22,28) ; 
add.pre.list (Jt(world [25] .pre.places) .Jtplace.ptr.array [59] , 
Jtplace.ptr.array [54] , 

NULL) ; 

add.post.list (Jt(world[25] .post .places) , Jtplace.ptr.array [58] ,0, 
Jtplace.ptr.array [0] , socket _arr [2] .NULL) ; 

initialize_transition.(rec_time2 ,TRAN world[26] ,14,32) ; 
add.pre.list (Jt (world [26] .pre.places) .Jtplace.ptr.array [56] , 
Jtplace.ptr.array [55] , 

NULL) ; 

add.post.list (Jt (world [26] .post .places) , Jtplace.ptr.array [45] ,0, 
Jtplace.ptr.array [4] , socket _arr [2] .NULL) ; 

initialize_transition(rec_time2 ,TRAN world[27] ,18,32) ; 
add.pre.list (A (world [27] .pre.places) .Jtplace.ptr.array [57] , 
Jtplace.ptr.array [55] , 

NULL) ; 

add.post.list (Jt(world[27] .post .places) , Jtplace.ptr.array [59] ,0, 
Jtplace.ptr.array [4] , socket.arr [2] .NULL) ; 

initialize_transition(rec_time2 .TRAN world[28] ,22,32) ; 
add.pre.list (Jt (world [28] .pre.places) .Jtplace.ptr.array [58] , 
Jtplace.ptr.array [55] , 

NULL) ; 

add.post.list (Jt(world[28] .post.places) , Jtplace.ptr.array [45] ,0, 
Jtplace.ptr.array [4] , socket.arr [2] .NULL) ; 

initialize_transition(continue_vision.TRAN world[29] ,2,12); 
add.pre.list (Jc(world [29] .pre.places) .Jtplace.ptr.array [30] , 
Jtplace.ptr.array [62] , 

NULL) ; 

add.post.list (Jt(world[29] .post.places) , Jtplace.ptr.array [61] ,0, 
Jtplace.ptr.array [16] .socket.arr [0] .NULL) ; 

initialize_transition(rec_time2 ,TRAN world[30] ,2,22) ; 
add.pre.list (Jt (world [30] .pre.places) .Jtplace.ptr.array [31] , 
Jtplace.ptr.array [61] , 

NULL) ; 

add.post.list (Jt(world[30] .post.places) , Jtplace.ptr.array [33] ,0, 
Jtplace.ptr.array [20] .socket.arr [0] .NULL) ; 
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initialize_transition(motion_task, TRAN world[3l] ,28 ,22) ; 
add_pre_list (4(world[3l] .pre_places) ,4place_ptr_array [46] , 
4place_ptr_ array [33] , 

NULL) ; 

add.post.list (4(world[3l] .post_places) , 4place_ptr_array[60] ,0, 
4place_ptr_array [5] , socket. arr [l] .NULL) ; 

initialize_transition(rec_time2 ,TRAN world[32] ,32,26) ; 
add_pre_list (4 (world [32] .pre.places) ,4place_ptr_array [48] , 
4place_ptr_ array [60] , 

NULL) ; 

add_post_list (4(world[32] .post .places) , 4place_ptr_array [62] ,0, 
4place_ptr_array [9] , socket.arr [l] .NULL) ; 


declare.enab .tokens (4(world [ll] 
declare. anab _t okens (4 (world [13] 
declare.enab .tokens (4(world [15] 
Approach, NULL) ; 

declare_enab_tokens(4(world[l6] 
Approach .NULL) ; 

declare. enab.t okens (4 (world [ 17] 
Approach, NULL) ; 

declare. enab.t okens (4 (world [18] 
Approach .NULL) ; 

declare_enab_tokens(4(world[0] . 
declare_enab_tokens(4(world[l] . 
declare_enab_tokens(4(world[2] . 
.NULL) ; 

declare_enab_tokens(4(world[3] . 
.NULL) ; 

declare.enab .tokens (4 (world [4] . 
.NULL) ; 

declare.enab.tokens (4(world[23] 
declare.enab.tokens (4(world [24] 
declare.enab.tokens (4(world[25] 
declare. enab.t okens (4 (world [29] 
declare.enab.tokens (4(world[3l] 


. menu.requirement s ) 
. menu.requirement s ) 
. menu.requirement s ) 


, CalR, NULL); 
, Move .NULL) ; 
, Move , 


. menu.requirement s) , Move, 
.menu.requirement s ) , Move, 
.menu.requirements) , Move, 


menu.requirements) , 
menu.requirements) , 
menu.requirements) , 


CalV.NULL) ; 
CalV , NULL); 
Look, Find 


menu.requirements). Look, Find 
menu.requirements) , Look, Find 


.menu.requirements) 
. menu.requirement s ) 
. menu.requirements ) 
. menu.requirements ) 
. menu.requirements ) 


, Rel.NULL); 

, Grip .NULL) ; 

, Rel.NULL) ; 

, Conti, NULL); 
, Slave, NULL) 


add.menu.cmnd(CalR) ; 
add.menu.cmnd(CalV) ; 
add.menu.cmnd(Move) ; 



add_memi_annd(Rel) ; 
add_memi_cmnd(Grip) ; 
add .menu _annd (Move) ; 
add_menu_cmnd(Approacli) ; 
add_memi_annd(Rel) ; 
add_menu_cnmd(Look) ; 
add_menu_cmnd(Find) ; 
add_menu_r.mnd(Move) ; 
add_men.u_cmnd(Find) ; 
add_menu_cmnd(Mov9) ; 
add_menu_annd(Move) ; 
add_menu_c:nnd (Approach) ; 

place.place (30 ,0,10) ; 
place_place(31 ,0 ,20) ; 
place_place(32 ,4, 18) ; 
place_place(33,4,28) ; 
place_place (34 ,6,18) ; 
place_place(35 ,8 , 18) ; 
place_place(36 , 10 , 18) ; 
place_place(37 , 12 , 18) ; 
place_place (38 ,16,10); 
place_place(39 ,18,8); 
place_place (40 ,22,0) ; 
place_place(41 ,22 ,4) ; 
place_place(42 ,22 ,8) ; 
place_place (43 ,22,12) ; 
place_place (44 ,22,18) ; 
place_place (45 , 20 , 24) ; 
place_place(46 ,26,0) ; 
place_place(48 ,32 ,4) ; 
place_place (SO ,30 , 18) ; 
place_place (5 1 ,30,20) ; 
place_place (52 ,30 ,22) ; 
place_place(53 ,30 ,26) ; 
place_place(54, 10 ,26) ; 
place_place (55 , 10 ,30) ; 
place_place (56 ,14,30) ; 
place_place(57 , 18 ,30) ; 
place_place(58 ,22,30) ; 
place_place (59 , 24 , 24) ; 
place_place(60 ,30 ,24) ; 
place_place(61 ,2, 18) ; 
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place_place(62 ,2 ,30) ; 
place_place(0 , 28,30); 
place_placa(4, 28,34); 
place_place(5 , 30,4); 
placa_place(9 , 36,8); 
place_place(16 , 0,16); 
place_place(20 , 0,24); 

> 

void initialize_marking(){ 
add_token(40 , 1) ; 
add_token (40 , 1 ) ; 
add_token(40 , 1) ; 
add_token(46 , 1) ; 
add_token(46 , 1) ; 
add.token (30 , 1 ) ; 
add_token(30 , 1) ; 
add_token(54, 1) ; 
add_token(54, 1) ; 

> 

int release_menu() 

i 

rec.timel () ; 

send_tape (socket _arr [2] ,AD_TAPE_END , GoPos, Retur, MULL); 
return (1) ; 

> 

int grasp_menu() 
rec_timel () ; 

send_tape(3ocket_arr [2] ,AD_TAPE_END , Cross, GoPos, 

Retur, MULL) ; 
return (l) ; 

> 

int calibrate_nenu() 

{ 

rec_timel () ; 

send_tape(socket_arr [0] ,AD_TAPE_END, CaLlV, CalV, CalV, CalV, 
CalV , CalV, Retur, NULL); 
retum(l) ; 


> 
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int find_menu() 

-c 

3 end_t ape ( socket _arr[0] ,AD_TAPE_END, Find, Retur, NULL); 
return(l) ; 

> 


int look_menu() 

{ 

send_tape (socket _axr [0] ,AD_TAPE_END , Look, Retur, NULL); 
return ( 1 ) ; 

> 

int vision_task() 

{ 

rec_timel () ; 

if (get _menu_ value () == (int)Find) retum(f ind_menu() ) ; 
else return(look_menu() ) ; 

> 

int motion_task() 
rec.timel C) ; 

if (get _menu_ value () *«* (int) Move) return(move_menu() ) ; 
else if (get_menu_value() *■ (int) Approach.) 
return (approach.menu () ) ; 

else if (get_menu_value() == (int) Slave) return (move_menu ()) ; 
else return (calr.menu ()) ; 

> 

int calr_menu() 

send_tape ( socket _arr [l] ,AD_TAPE_END , CalR, NULL); 
retum(l) ; 

> 

int approach_menu() 

send_tape(socket_arr[l] ,AD_TAPE_END , Approach, NULL); 
retum(l) ; 

> 


int move_menu() 



{ 

send.tape (socket _arr[l] ,AD_TAPE_END , Move, NULL); 
return (1) ; 

> 

int continue_vision() 
rec_timel() ; 

send_tape(socket_arr [0] ,AD_TAPE_IMMEDIATE, Conti, NULL) 
return (1) ; 

> 

B.2 setup_arm.c 

This file describes the Petri net for the Motion Coordinator. 


/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 
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** 

** Package: TokenPasser 
** 

** File: setup.arm.c 
** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main . c . 

** This file contains the statements needed to define a net 
** identical to the one in "mittmann/nets/motion.full.io 

** 

** Modification History: 

** 

*/ 

#include <varargs.h> 

♦include "pet.h" 

♦include "pet2.h" 

♦include "dumb_dec.h" 

♦define NTJM.TRANS 9 

char title Q = {"Arm"}; 

extern int socket_arr[]; 

int number_of .sockets * LQCAL.SOCKS ; 

int menu[SIZE_MENU] ; 

int num.transitions = NUM.TRANS; 

struct place.ptr place.ptr.array [16] ; 

struct transition world [NUM.TRANS] ; 

/* 

* make.net () 

* this routine just defines a net identical to the one described 

* in the GreatSPN1.5 file motion.full.io . 

* 

* Arguments: none 

* Returns : nothing 

* Requirements: just about all of the routines linked to it ) 

* - — — _________ — — _____ — */ 



{ 

initialize_transition(dusuny ,TRAN world[0] ,2,4); 
add.pre.list (4 (world [0] .pre.places) , 4place_ptr_array [5] , 
4place_ptr_array [6] , 

NULL) ; 

add.post.list (4(world[0] . post .places) , 4place_ptr_array [7] ,0, 
NULL) ; 

initialize_transition(dummy ,TRAN worldCl] ,2,8) ; 
add.pre.list (4 (world [l] .pre.places) , ftplace.ptr. array [7] , 

NULL) ; 

add.post.list (4(world[l] .post .places) , 4place_ptr_array [8] ,0, 
NULL) ; 

initialize_transition(dummy ,TRAN world[2] ,6,8); 
add.pre.list (4 (world [2] .pre.places) , 

4pl ace.pt r_ array [7] ,4place_ptr_array [9] , 

NULL) ; 

add.post.list (4(world[2] .post .places) , 4place_ptr_array [6] ,0, 
4place_ptr_array [46] , socket _arr[0] , 

4place_ptr_array [48] , 
socket _arr[0] .NULL) ; 

initialize_transition(dummy ,TRAN vorld[3] ,6,10) ; 
add.pre.list (4(world [3] .pre.places) , 4place_ptr_array [9] , 
4place_ptr_array [10] , 

4place_ptr_array [ll] , NULL) ; 

add.post.list (4(world[3] .post .places) , 4place_ptr_ array [6] ,0, 
4place_ptr_array [46] ,socket_arr[0] , 

4place_ptr_array [48] , 
socket _arr[0] .NULL) ; 

initialize. transit ion (dummy ,TRAN world[4] ,2,12) ; 
add.pre.list (4(world[4] .pre.places) , 4place_ptr_array [8] , 

NULL) ; 

add.post.list (4(world[4] .post.places) , 4place_ptr_ array [13] ,0, 
4place_ptr_array [10] ,0,NULL) ; 

init ialize.trans it ion ( dummy , TRAN world[5] ,2,16) ; 
add.pre.list (4(world[5] .pre.places) , 4place_ptr_ array [12] , 
4place_ptr_array [13] , 

NULL) ; 

add_post_list(4(vorld[5] .post.places), 4place_ptr_array [14] ,0, 


NULL) ; 


initialize_transition(duinmy ,TRAN vorld[6] ,8,18) ; 
add.pre.list (A (world [6] .pre.places) , iplace.ptr. array [15] , 
NULL) ; 

add.post.list (A(world[6] .post.places) , fcplace.ptr. array [11] ,0, 
&place_ptr_array[12] , 0, NULL); 

initialize_transition(duainiy ,TRAN world[7] ,4,20) ; 
add.pre.list (4 (world [7] .pre.places) , Aplace.ptr. array [15] , 
NULL) ; 

add.post.list (A(vorld[7] .post .places) , ftplace.ptr. array [14] ,0, 
NULL) ; 

initialize_transition(dummy ,TRAN world[8] ,4,24) ; 
add.pre.list (& (world [8] .pre.places) , ftplace.ptr. array [14] , 
NULL) ; 

add.post.list (&(world[8] .post .places) , tplace.ptr. array [15] ,0, 
NULL) ; 

declare_enab_tokens(4(world[0] .menu.requirements) , Move, 
Approach, CalR, NULL) ; 

place_place(5 , 20,2); 
place_place(6 , 2, 2); 
place_place(7 , 2 ,6); 
place_place(8 , 2 ,10); 
place_place(9 , 20,6); 
place.place (10,8, 14) ; 
place_place(ll ,6 , 16) ; 
place_place(l2 ,4, 14) ; 
place.place (13,2, 14) ; 
place.place (14, 2, 22) ; 
place_place(15 ,6 ,22) ; 
place.place (46 , 20,10); 
place.place (48 , 20,14); 

> 

void initialize_marking(){ 
add_token(6 , 1) ; 
add_token(9 , 1) ; 
add. token (12,1) ; 

> 



B.3 setup_grip.c 

This file describes the Petri net for the Gripper Coordinator. 

/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute. 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 
** useful. BUT, in no event will the authors or Rensselaer 
** be liable for any damages whatsoever, including any lost 
** profits, lost monies, business interruption, or other 
** special, incidental or consequential damages arising out 
** of the use or inability to use (including but not 
** limited to loss of data or data being rendered 
** inaccurate or losses sustained by third parties or a 
** failure of this software to operate) even if the user 
** has been advised of the possibility of such damages, or 
** for any claim by any other party. 

** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: setup .grip. c 
** Written By: Michael Mittmann 

** Date: 1/30/91 

★ * 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains the statements needed to define a net 
** identical to the one in "mittmann/nets/grip . nonames. full. 


** Modification History: 

** 

*1 

# include < var ar gs . h> 

#include "pet.h" 

#include "pet2.h" 

#include "dumb.dec.h" 

tf define NUM.TRANS 8 

char titled = {"Gripper"}; 

extern int socket.arrd ; 

int number.of .sockets = LOCAL.SOCKS; 

int menu[SIZE_MENU] ; 

int num.transitions = NUM .TRANS ; 

struct place.ptr place.ptr.axray [6] ; 

struct transition world [NUM.TRANS] ; 

/* ~ 

* make.net O 

* this routine just defines a net identical to the one described 

* in the GreatSPN1.5 file grip .nonaaes .full. io 

* 

* Argument s : none 

* Returns : nothing 

* Requirements: just about all of the routines linked to it ;-) 

* * 

make.net () 

{ 

initialize_transition(dummy ,TRAN world[0] ,2,4) ; 
add.pre.list (4 (world [0] .pre.places) , fcplace.ptr.array [0] , 
&place_ptr_array [l] , 

NULL) ; 

add_post_list(a:(world[0] .post.places) , kplace.ptr.array [2] ,0, 
NULL) ; 

initialize. transit ion (dummy ,TRAN world[l] ,2,8) ; 
add.pre.list (ft(world[l] .pre.places) , fcplace.ptr.array [2] , 

NULL) ; 

add.post.list (&(world[l] .post.places) , iplace.ptr.array [3] ,0, 
NULL) ; 
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initialize_transition(dummy ,TRAN world[2] ,4,8) ; 

add.pre.list (A (world [2] .pre.places) , ftplace.ptr.array [2] , 
NULL) ; 

add_post_list (4 (world [2] . post .places) , ftplace.ptr.array [3] ,0, 
NULL) ; 

initialize_transition(duininy ,TRAN world[3] ,6,8) ; 

add.pre.list (ft (world [3] .pre.places) , ftplace.ptr.array [2] , 
NULL) ; 

add.post.list (ft(world[3] .post .places) , ftplace.ptr.array [3] ,0, 
NULL) ; 

initialize_traasition(dummy ,TRAN vorld[4] ,8,8) ; 

add.pre.list (ft (world [4] .pre.places) , ftplace.ptr. array [2] , 
NULL) ; 

add.post.list (&(world[4] .post.places) , ftplace.ptr. array [3] ,0, 
NULL) ; 

init ialize.t rans it ion (dummy , TRAN world[5] , 10,8) ; 

add.pre.list (ft (world [5] .pre.places) , ftplace.ptr. array [2] , 
NULL) ; 

add.post.list (4(world[5] .post.places) , ftplace.pt r.array [3] ,0, 
NULL) ; 


initialize_transition(dummy .TRAN world[6] ,2,12) ; 
add.pre.list (ft (world [6] .pre.places) , ftplace.ptr.axray [3] , 
ftplace.ptr. array [4] , 

NULL) ; 

add.post.list (ft(world[6] .post.places) , ftplace.ptr.array [54] , 
socket _arr[0] , 

ftplace.ptr.array [l] ,0, 

ftplace.ptr.array [55] , socket _arr[0] .NULL) ; 


initialize_transition(dummy ,TRAN world[7] ,14,8) ; 
add.pre.list (ft (world [7] .pre.places) , ftplace.ptr.array [3] , 
NULL) ; 

add.post.list (ft(world[7] .post.places), ftplace.ptr.array [2] ,0, 
NULL) ; 


declaxe.enab.tokens (ft(world[l] .menu.requirements) , 
declaxe.enab.tokens (ft(world[2] .menu.requirements) , 
declare_enab_tokens(ft(world[3] .menu.requirements) , 
declare.enab.tokens (ft(world[4] .menu.requirements) , 


MeaFo , NULL) ; 
GoFor, NULL) ; 
MeaPo, NULL); 
GoPos, NULL) ; 


a 
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declare_enab_tokens(4(world[5] .menu.requirements) , Cross, NULL); 
declare_enab_tokens(&(world[6] .menu.requirements) , Retur, NULL); 

place_place(0, 20,2); 
place_place(l , 2, 2); 
place_place(2, 2 ,6); 
place_place(3, 2 ,10); 
place_place(4, 20,10); 
place_place(54, 20,14); 
place_place(55 , 20,16); 

> 

void initialize_marking(){ 
add_token(l , 1) ; 
add_token(4, 1) ; 

> 


B.4 setup_vision.c 

This file describes the Petri net for the Vision Coordinator. 


/* 

** NOTICE OF COPYRIGHT 

** Copyright (C) Rensselaer Polytechnic Institute. 

** 1990 ALL RIGHTS RESERVED. 

** 

** 

** Permission to use, distribute, and copy is granted ONLY 
** for research purposes, provided that this notice is 
** displayed and the author is acknowledged. 

** 

** This software is provided in the hope that it will be 

** useful. BUT, in no event will the authors or Rensselaer 

** be liable for any damages whatsoever, including any lost 

** profits, lost monies, business interruption, or other 

** special, incidental or consequential damages arising out 

** of the use or inability to use (including but not < 

** limited to loss of data or data being rendered 

** inaccurate or losses sustained by third parties or a 

** failure of this software to operate) even if the user 

** has been advised of the possibility of such damages, or 

** for any claim by any other party. 
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** 

** This software was developed at the facilities of the 
** Center for Intelligent Robotic Systems for Space 
** Exploration, Troy, New York, thanks to generous project 
** funding by NASA. 

** 

** Package: TokenPasser 
** 

** File: setup.vision. c 

** 

** Written By: Michael Mittmann 
** 

** Date: 1/30/91 
** 

** Purpose: The purpose of the package can be found in the file 
** main.c. 

** This file contains the definitions needed to define a vision 
** net identical to the one in "niittmann/nets/vision3_full_io . 

** 

** Modification History: 

*/ 

•include <varargs.h> 

•include "pet.h" 

•include "pet2.h" 

•include "dumb_dec.h" 

•define NUM.TRANS 16 

char titled ={"Vision"} ; 
extern int socket_arr[] ; 
int c mmn d.armQ ; 

int number.of .sockets = L.QCAL.S0CKS; 
int menu [SIZE .MENU] ; 
int num.transitions = NUM.TRANS ; 
struct place.ptr place.ptr.array [32] ; 
struct transition world [NUM.TRANS] ; 

/* 

* make.net () 

* this routine just defines a net identical to the one described 

* in the GreatSPNl.5 file vision3_full_io 

* 

* Arguments : none 


i 


* Returns : nothing 

* Requirements : just about all of the routines linked to it , ) 

* 

make_netO 

{ 

initialize_transition(dummy ,TRAN world[0] , 18,4) ; 
add.pre.list (ft (world [0] .pre.places) , ftplace.ptr.array [16] , 
ftplace.ptr.array [17] , 

NULL) ; 

add_post_list (ft(world[0] .post .places) , ftplace.ptr. array [19] ,0, 
NULL) ; 

initialize_transition(dummy ,TRAN world[l] ,8,4) ; 
add.pre.list (ft (world [l] .pre.places) , ftplace.ptr.array [16] , 
ftplace.ptr.array [17] , 

NULL) ; 

add.post.list (ft(world[l] .post .places) , ftplace.ptr.array [18] ,0, 
NULL) ; 

initialize_transition(dummy ,TRAN world[2] ,2 , 16) ; 
add.pre.list (ft (world [2] .pre.places) , ftplace.ptr.array [16] , 
ftplace.ptr.array [17] , 

NULL) ; 

add_post_list(ft(world[2] .post.places) , ftplace.ptr.array [24] ,0, 
NULL) ; 

initialize_transition(dummy ,TRAN world[3] ,12,8) ; 
add.pre.list (ft(world[3] .pre.places) , ftplace.ptr.array [19] , 

NULL) ; 

add.post.list (&(world[3] .post.places) , ftplace.ptr.array [18] ,0, 
NULL) ; 

initialize_transition(dununy ,TRAN world[4] , 18, 10) ; 
add.pre.list (ft (world [4] .pre.places) , ftplace.ptr.array [19] , 
ftplace.ptr.array [20] , 

NULL) ; 

add.post.list (ft(world [4] .post.places), ftplace.ptr.array [17] ,0, 
ftplace.ptr.array [30] , socket _arr[0] , 
ftplace.ptr.array [31] , socket _arr [0] , NULL) ; 

initialize_transition(cmmnd_arm,TRAN world[5] ,8,12) ; 
add.pre.list (ft(world[5] .pre.places) , ftplace.ptr.array [18] , 



4place_ptr_array [20] , 

MULL) ; 

add_post_list (4(world[5] .post_places) , 4place_ptr_ array [22] ,0, 
4place_ptr_ array [30] , socket_arr [0] , 

4place_ptr_array [31] , socket_arr[0] , NULL) ; 

initialize_transition(dummy ,TRAN world[6] ,0,0) ; 

initialize_transition(dummy,TRAN world[7] ,12,12) ; 
add_pre_list (4 (world [7 ] .pre_places) , 4place_ptr_array [16] , 
NULL) ; 

add_post_list (4(world[7] . post_places) , 4place_ptr_ array [23] ,0, 
NULL); 

init ialize_trans it ion (dummy , TRAN world[8] ,8,16) ; 
add_pra_list (4 (world [8] . pre_places) , 4place_ptr_array [22] , 
4place_ptr_ array [23] , 

NULL) ; 

add_post_list (4(world[8] . post.places) , 4place_ptr_array [24] ,0, 
NULL); 

initialize_transition(dummy ,TRAN world[9] ,8,20) ; 
add_pre_list (4 (world [9] .pre_places) , 4placa_ptr_ array [24] , 
4place_ptr_array [28] , 

NULL) ; 

add_post_list (4 (world [9] ,post_places) , 4place_ptr_array [25] ,0, 
NULL) ; 

init ialize.trans it ion (dummy , TRAN world[l0] ,18,20) ; 
add_pre_list (4(world[l0] .pre.places) , 

4place_ptr_array [20] ,4place_ptr_array[22] , 

4place_ptr_array [23] , NULL) ; 

add_post_list (4 ( world [ 10] .post_places) , 4place_ptr_array [17] ,0, 
4place_ptr_array [30] , socket _arr [0] , 

4place_ptr_array [31] , 
socket _arr[0] ,NULL) ; 

initialize_transition(dummy ,TRAN world[ll] ,8,24) ; 
add_pre_list (4(world [l 1] . pre_places) , 4place_ptr array [25] , 
NULL) ; 

add_post_list(4(world[ll] ,post_places) , 4place_ptr array[26],0, 
NULL) ; 
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initialize_transition(dummy ,TRAN world[12] ,8,28) ; 

add.pre.list (4 (world [12] .pre.places) , 4place_ptr_array [26] , 

MULL) ; 

add_post_list(4(world[12] .post .places) , 4place_ptr_ array [29] , 0 , 

NULL) ; 

initialize_transition(dummy ,TRAN vorld[13] ,8,32) ; 

add_pre_list (4 (world [13] .pre.places) , 4place_ptr_array [20] , 
4place.pt r.array [29] ,NULL) ; 

add_post_list (4(world[l3] .post .places) , 4place_ptr_ array [17] ,0, 
4place.pt r.array [28] ,0, 

4place.pt r.array [30] , socket _arr[0] , 

4place_ptr_array [31] , 
socket _arr[0] .NULL) ; 

init ialize.trans it ion (dummy , TRAN world[l4] ,4,28) ; 

add.pre.list (4 (world [14] .pre.places) , 4place_ptr_array [26] , 

NULL) ; 

add.post.list (4(world[l4] .post.places) , 4place_ptr_array [27] ,0, 
4place_ptr_ array [18] ,0 , NULL); 

initialize.transitionCdummy .TRAN world[l5] ,4,32); 

add.pre.list (4(world [15] .pre.places) , 4place_ptr_array [27] , 

NULL) ; 

add.post.list (4(world[15] .post.places) , 4place_ptr_ array [28] ,0, 
NULL) ; 


declare_enab_tokens(4(world[0] .menu.requirements) , Look, NULL); 
declare_enab_tokens(4(world[l] .menu.requirements) , CalV, NULL); 
declare.enab .tokens (4 (world [2] .menu.requirements) , Find, NULL); 
declare_enab_tokens(4(world[4] .menu.requirements) , Retur, NULL); 
declare.enab.tokens (4(uorld [7] .menu.requirements) , Conti, NULL); 
declare_enab_tokens(4(world[8] .menu.requirements) , CalV,- NULL) ; 
declare_enab_tokens(4(world[l0] .menu.requirements) , Retur, NULL); 
declare.enab.tokens (4(world [12] .menu.requirements) , Retur, NULL); 


place_place(l6 ,28 ,2) ; 
place_place(17 ,8 ,2) ; 
place_place(18 ,8 , 10) ; 
place_place( 19 , 18,6); 
place_place(20 , 28,8); 



place_place(22 ,8 , 14) ; 
place_place(23 , 12 , 14) ; 
place_place(24,8, 18) ; 
place_place(25,8,22) ; 
place_place(26,8,26) ; 
place_place(27,4,30) ; 
place_place(28 ,4,34) ; 
place_place(29 ,8,30) ; 
place_place (30 , 28,22); 
placa_place(31 , 28,34); 

> 

void initial ize_marking(){ 
add_token (17,1) ; 
add_token (20 , 1 ) ; 
add_token (28 , 1 ) ; 

> 

int cmmnd_arm() 

send_tape(socket_arr [0] ,AD_TAPE_IMMEDIATE, Conti, Slave, 
NULL) ; 
retum(l) ; 

} 


